Address Codex audit of ticking (36c0cfa): dynamic + init-race fixes

P1 - Tick cadence now reacts immediately to changing tilt. The due time is
recomputed every update from the last-tick anchor plus the CURRENT interval,
so dropping from 5deg to 0.4deg accelerates to the fast cadence at once
instead of waiting out the stale slow interval. Anchor advances by whole
intervals (no drift) and resyncs to now if a full interval behind (no burst).
Added far->near and near->far transition tests.

P1 - One-shot cues no longer lost to async loading. SonarSoundPool queues a
Level asked for before its sample loads and plays it on load-complete (and
cancels the queued Level on unlock/gate). VoiceSpeaker queues the latest
phrase requested before TTS finishes init and speaks it on ready. The policy
fires these once, so they can't rely on retries.

P2 - Unlock stops the level.wav tail BEFORE playing the resumed tick (order
was reversed, allowing a brief overlap).

P2 - Audio-mode preference write moved from the screen's rememberCoroutineScope
to container.applicationScope, so a quick navigation can't cancel it (matches
the earlier persistence hardening).

Cleanup: AudioAssistMode and LevelPipeline comments now describe ticking, not
the retired radar pings/homing bands; AUDIO_DESIGN_LOG cadence principle
reconciled with the 125 ms continuous-tick near rate.

78 tests passing; assembleDebug clean.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

AUDIO_DESIGN_LOG.md

@@ -65,10 +65,12 @@ mono 44.1 kHz in `res/raw`.
 
 ## Guiding principles (learned)
 
-- Leave **air** between cues; silence is restful. (600 ms near cadence is responsive without
-  being alarm territory; ~180 ms was alarm territory.)
-- **Pitch** carries distance more reliably than **volume** (phone volume + room noise make
-  loudness a poor information channel).
+- Cue *character* decides tolerance more than raw rate. As **discrete report cues**, ~180 ms
+  spacing felt alarm-like and ~600 ms felt calm — but as a **continuous proximity tick** an
+  8/s (125 ms) near rate reads as pleasant acceleration, not an alarm (it's a Geiger/parking
+  sensor, and the ear expects it to quicken as you close in). Judge by feel on the phone.
+- **Volume** is a poor information channel (phone volume + room noise make loudness
+  unreliable) — let rate/pitch carry the message and keep loudness constant.
 - Keep the SoundPool layer dumb; put decisions in tested pure logic.
 - The **centered** sound needs source loudness/spectrum presence, not just a bigger volume
   number.