fix(stepdown): restart the audio pipe around encoder changes

A quality step-down now closes the named audio pipe before stopping/flushing the
pump, then opens a fresh server before restarting the pump. This prevents ffmpeg
from waiting on the old audio input and avoids reconnecting to a broken pipe.

EncoderRestartTests pins the audio-stop → video-stop → audio-start → video-start
order. 616 tests green, clean build with 0 warnings.

docs/ai/output.md

@@ -248,8 +248,10 @@ devices, no timers).
   mixer at construction, read live each tick, so the volume sliders and mute buttons are stream-honest.
   (Before this wiring the seams defaulted to unity and the controls were decorative.) `StopStream` →
   `StopLive()` (closes the pipe → ffmpeg audio EOF) **BEFORE** stopping the frame pump (video EOF) —
-  the reverse order stalls on pipe backpressure. `FfmpegEncoder` itself is untouched; the VM owns the
-  pipe lifecycle.  **Recordings are fragmented MP4 (TASK 32·4, 2026-11-05):** the record block carries
+  the reverse order stalls on pipe backpressure. Encoder step-down follows the same order: close the
+  audio pipe, flush/stop the pump, create a fresh server on the same name, then restart the pump so ffmpeg
+  connects to a live server. `FfmpegEncoder` itself is untouched; the VM owns the pipe lifecycle.
+  **Recordings are fragmented MP4 (TASK 32·4, 2026-11-05):** the record block carries
   `-movflags +frag_keyframe+empty_moov+default_base_moof`, so the index is written first and a playable
   fragment is flushed at every keyframe. A plain MP4 puts its index at the end, which is why a power cut
   or a killed process previously left the whole take unreadable. The FLV stream block never gets it.