run_loop: a slow chime-playback failure loses post-wake audio (mic stopped during the failure window)

[jamditis]

Problem

run_loop's chime_for_turn (pipeline.py) pauses the mic before playing the
wake cue, half-duplex:

mic.pause()        # audio.Microphone.pause() -> stream.stop(): capture halts
flushed = False
try:
    audio.play_wav(cue_wav, output_name)
except Exception:
    print(...)     # failure: skip the flush
else:
    mic.flush()
    flushed = True
mic.resume()
return flushed

mic.pause() calls self._stream.stop() (audio.py:198), so the input callback
stops firing and no audio is captured during the pause. If audio.play_wav
blocks (device open, partial playback) and then raises, the mic was stopped for
that whole span. Any command audio the user speaks during the failed-cue window
is never captured. Returning False preserves only the pre-wake detection
pre-roll; the post-wake audio lost during the pause is unrecoverable. So the
failure path can clip or drop the command instead of degrading to the no-chime
behavior, where the mic is never paused and the command is captured.

Severity

Narrow. Requires wake_chime enabled + a slow-then-fail playback + the user
speaking during the failure window. A clipped/lost command lowers STT confidence,
so guard_transcript likely re-prompts rather than dispatching a wrong action --
degraded UX, not a wrong-action path. The default flow (chime off) is unaffected.

Direction

The audio dropped while the stream is stopped cannot be recovered after the fact,
so the fix is about bounding and handling the failure window:

• Keep the failure window minimal: the cue file is pre-rendered once at loop
  start, so the in-loop failure is a playback/device error -- detect a fast-fail
  path where possible before committing to the pause.
• On failure, degrade explicitly to no-chime semantics for the rest of the turn
  (resume without flush, which the code already does) and document that the
  window's audio is lost.
• Full-duplex capture during the cue (capturing through the cue and subtracting
  its known waveform) is out of scope and device-dependent.

The chime is opt-in and default off, so this is a robustness item for the
experimental path, not a blocker for the default flow.

Related

• live_driver: size the post-cue chime drain by flush-to-now, not subprocess wall time #56 -- the live_driver post-cue drain counterpart of the same half-duplex
  chime tension.
• From the Add a wake-word acknowledgment chime #41 review (chatgpt-codex-connector P2, pipeline.py:974).

[jamditis]

Decision from the #57 review: accept-and-document.

#58 stays open as the tracked capture-through-cue follow-up. The run_loop pause's cue-failure window (post-wake audio lost while the input stream is stopped) is an accepted limitation: opt-in (wake_chime default off), and on failure run_loop resumes without flush, degrading to no-chime semantics where a clipped command re-prompts via guard_transcript rather than dispatching a wrong action. Not a #57 blocker; the default flow is unaffected.

Same half-duplex class as #56 (the live_driver residual teardown-window clip) and #55 (gate the cue on a pause so a no-pause command and the cue can coexist). Capture-through-cue would address all three; revisit together when the half-duplex path is reworked.