fix(audio): smooth playback-rate transitions across native outputs

[mom0ka27]

Summary

• Preserve a 250ms old-rate PCM bridge while SoundTouch initializes and new-rate audio is prepared.
• Defer the playback clock rate update until the bridge has played, avoiding an abrupt audio/video clock transition.
• Reuse SoundTouch buffers and cap fast-rate audio pumping to 4ms per render tick.
• Bound Android AAudio and OpenHarmony OHAudio callback queues to 250ms through presenter-side backpressure.
• Align worker audio prefill with the same 250ms high-water mark so stale-rate PCM does not accumulate in intermediate channels.

Root Cause

iOS AudioQueue pre-fills three 20ms output buffers. The previous 80ms bridge could not reliably cover both the queued output and SoundTouch warm-up after a rate change, causing a short audio starvation and visible hitch.

Android and OpenHarmony use SPSC callback queues. Clearing or rewriting those queues during playback would race the realtime consumer. The new path instead stops draining decoded frames into a full callback queue, allowing existing worker-channel backpressure to preserve a bounded old-rate bridge safely.

Validation

• cargo test -p erika --lib audio::tests::output_queue_high_water_bounds_rate_transition_latency -- --exact
• cargo test -p erika --lib audio::tests::ring_buffer_rate_change_keeps_a_full_prefill_bridge -- --exact
• cargo test -p erika --lib core::tests::buffering_audio_recovery_requires_low_water_mark -- --exact
• iOS aarch64-apple-ios Release staticlib build passed.