feat(audio): the mic delay gets a slider, and the log states the applied value

Two gaps in what 7f89534 shipped, both caught by the creator's report that sound still
leads the lips:

- The mic delay had presets only (off / 150 / 200), so the value a slower camera needs —
  roughly 175 ms of residual on top of the 175 ms already applied — could not be set at
  all. Now a 0..500 ms slider with off / 175 / 350 presets.
- Nothing recorded which number was in force. The setting lives in the layout DB, so a
  preset click left no trace in the log; "Audio live: started" now names it.

Confirmed meanwhile from the profile: Audio.MicSyncOffsetMs is 175, so the delay is being
applied — the 150 ms of digital silence at the head of the 12:22 track is the delay line
priming, which is what an applied delay looks like. The residual offset is the camera's
pipeline being slower than 175 ms, not a missing delay.

674 pass, 0 warnings.

docs/ai/output.md

@@ -296,7 +296,10 @@ devices, no timers).
   alert audio are not tied to a camera frame and must not move with it. Seam: `Func<int> micSyncOffsetMs`
   (VM `MicSyncOffsetMs`, **0..500 ms**, persisted `Audio.MicSyncOffsetMs`, shipped default **175** —
   the creator's own C920 measurement, not a constant: the right number belongs to the machine).
-  Presets `off / 150 / 200` sit in the LIP-SYNC bay under the whole-mix slider. Both lines are
+  A **slider 0..500** plus `off / 175 / 350` presets sit in the LIP-SYNC bay under the whole-mix
+  slider — presets alone could not express the value a slow camera actually needs. `Audio live: started`
+  logs the applied number, because the value lives in the layout DB and a preset click is invisible in a
+  recording. 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