Remove Unity resampling

[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. The same lazy-create path is reused to recreate the native audio stream when Unity's delivered format changes mid-stream — for example after a system audio device switch.

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 CreateOrRecreateFfiStream(...) to the main thread via FfiClient._context, build the NewAudioStreamRequest with the observed values, and only then subscribe to AudioStreamEventReceived.
• Recreate the native stream when Unity's delivered format changes. A single gate in OnAudioRead covers both first-create and runtime mismatch (channels != _ffiNumChannels || sampleRate != _ffiSampleRate). On mismatch we post the same CreateOrRecreateFfiStream to the main thread; the new stream is built outside the lock, then under the lock we swap _handle, update the _ffi* trackers, clear the buffer, reset priming, and clear the _pendingFfiRequest flag. Old handle is disposed AFTER the swap so its Rust task exits cleanly. OnAudioStreamEvent drops frames while _pendingFfiRequest is set so old-format bytes don't land in the new buffer; the existing handle-id filter catches any in-flight stragglers from the old stream after the swap. This pairs with Recover AudioStream when system audio output device changes #274 (re-attach AudioProbe and re-Play() the AudioSource on device change) so audio resumes seamlessly when the user plugs/unplugs headphones, switches Bluetooth devices, etc.

Files

• Runtime/Scripts/AudioStream.cs — _resampler field gone; Handle is now _handle behind a property; CreateOrRecreateFfiStream added; _ffiNumChannels/_ffiSampleRate/_pendingFfiRequest track FFI-side configuration; 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%