Remove Unity resampling by configuring native audio source correctly

[MaxHeimbrock]

Summary

Remove second resampling in Unity, by configuring the Rust audio stream with correct (channels, sampleRate) to begin with. The problem is, that in Unity you don't know the channel number of each audio source until it runs, so we need to delay the initialization of the native audio stream until audio is read in Unity.

Changes

• Drop C# RemixAndResample per-frame path. OnAudioStreamEvent now just memcpys the inbound AudioFrame into the ring buffer — no FFI roundtrip on the OS-audio-scheduled callback thread. Rust's NativeAudioStream does the rate/channel conversion internally, once, with its existing pipeline.
• Lazily create the FFI native stream from the first OnAudioRead. AudioSettings.GetConfiguration().speakerMode disagrees with what OnAudioFilterRead actually delivers when the AudioSource is routed differently (per-source mono routing, spatializers, mixer chains, headphone profiles) — observed on macOS Editor + Sony headphones (system Stereo, source mono → low-pitched playback). The first callback is the authoritative source for (channels, sampleRate); we post a one-shot CreateFfiStream(...) to the main thread via FfiClient._context, build the NewAudioStreamRequest with the observed values, and only then subscribe to AudioStreamEventReceived.
• No reconfigure / handle swap path. Because we never create the stream with a wrong guess, there's no old/new stream window with in-flight frames to reconcile.

Files

• Runtime/Scripts/AudioStream.cs — _resampler field gone; Handle is now _handle behind a property; CreateFfiStream added; constructor only sets up AudioSource/AudioProbe/pause hook.
• Tests/EditMode/MediaStreamLifetimeTests.cs — assertions updated for the renamed/removed members.

Profiler

Before change, after 5 minutes and multiple audio sources: Total Audio CPU reaches ~100%

---

With change, after 5 minutes and multiple audio sources: Total Audio CPU stays below ~10%