fix(audio): drive the mix from the clock — the audio track was 2.1% longer than the show

Measured on the creator's recording (ty-20261112-1118-423-0000-2.mp4), which drifts
out of sync over ten seconds:

  wall clock (pump start -> audio stop)   9.875 s
  video: 594 frames, uniform 1/60         9.888 s   correct
  audio: 485,376 samples @ 48 kHz        10.112 s   +2.1%, 224 ms long

So it was not VFR and not wall-clock PTS: the video is CFR and matches the clock (the
only PTS anomaly in the file is one 38 ms gap from two lost frames). The audio track is
what was too long, and a static offset cannot fix a rate error — which is why the opening
looked aligned (the 175 ms mic delay cancels the camera's constant pipeline latency) and
the end did not.

Cause: LiveLoopAsync wrote a fixed 480 frames per iteration and trusted that each
iteration was 10 ms. Under a raised timer resolution they land near 9.8 ms — 102 ticks
per second where 100 are expected, i.e. 102% of an audio second per wall second. FFmpeg
stamps audio by sample count, so every second of show pushed the sound ~2% later against
a correct picture. Video never had the bug because the pump paces off a stopwatch.

Fix: Services/Audio/AudioClock asks the clock how many frames are owed
(expected - produced, clamped to one 200 ms chunk) and the loop produces exactly that,
padding on underrun. A stalled loop pays its debt over the following ticks instead of
dumping one huge write. FillAndMix takes a frame count, and the master limiter/meter take
spans, so a partial chunk is processed without touching stale buffer tail.

674 tests (one log-rotation flake under full-suite load while the app itself is running
and writing startup.log; passes alone), 0 warnings. Ear check pending.

docs/ai/output.md

@@ -299,6 +299,15 @@ devices, no timers).
   Presets `off / 150 / 200` sit in the LIP-SYNC bay under the whole-mix slider. Both lines are
   reconfigured every tick, so both carry the 2026-09-12 warning: a `Configure` that reallocates
   discards the buffered audio every 10 ms.
+- **The audio clock is the wall clock, not the tick count (2026-11-12).** `LiveLoopAsync` asks
+  `Services/Audio/AudioClock.FramesDue(elapsed, produced, rate, maxChunk)` how many frames are owed and
+  produces exactly that, instead of writing a fixed 480 frames per iteration. The fixed version turned a
+  scheduler error into a permanent A/V rate error: iterations land near 9.8 ms rather than 10, which is
+  102 ticks/s where 100 are expected — 2.1% more audio than wall time. Measured on a 9.9 s recording:
+  **video 9.888 s (correct, 594 frames at 60 fps), audio 10.112 s**, so the sound slid ~200 ms behind
+  the lips across ten seconds and no static delay could fix it. Buffers size to the largest chunk the
+  planner may return (`OutputSampleRate / 5`), and a stalled loop pays its debt over the following ticks
+  rather than dumping one huge write. Video never had this bug — the pump paces off a stopwatch.
 - **TRAX — free background music (TASK 8):** `MusicPlayer` = NAudio `MediaFoundationReader`
   (mp3/wav/m4a) → `VolumeWaveProvider16` at the hardcoded **0.20** bed (no slider) → `WaveOutEvent` on
   the default device, **looping on any clean natural end** (`PlaybackStopped` with `e.Exception == null`