Gate the wake chime on a pause so it does not clip no-pause commands

[jamditis]

The wake chime (#41) and the pre-roll no-pause capture (#30) conflict on a
half-duplex device (the PowerConf is a shared mic+speaker; the cue cannot play
while the mic captures).

When wake_chime is enabled, a command spoken in one breath with the wake word --
"computah file an issue about X" -- arrives during the cue window and is lost:

• live_driver (Pi/arecord): the post-cue drain discards the frames recorded while
  the cue played, which on a no-pause command are the start of the command, so the
  leading word(s) clip.
• run_loop (desktop/sounddevice): the mic is paused during the cue and flushed
  before capture, so a command finished during the cue is dropped entirely
  (capture_request's onset ignores the pre-roll, so it returns empty).

This regresses exactly the no-pause case #30 protects. Found by Codex review of #41.

Current mitigation (shipped in #41): the chime is opt-in, default off, so the
default flow is unaffected. The conflict only occurs when a user enables the cue.

Proposed fix: gate the cue on a pause. After the wake fires, peek the immediate
post-wake audio; if speech is already present (no-pause), skip the cue and capture
the request intact (pre-roll path untouched). If the post-wake audio is silent (the
user is waiting), play the cue, then capture -- draining the cue window is safe then
because no command audio is in it. This needs a short onset-peek window (a tunable,
like _PREROLL_FRAMES) and a hardware validation pass on the PowerConf.

Acceptance:

• With wake_chime on, "computah file an issue about X" (one breath) transcribes
  intact -- no clipped leading word, on both live paths.
• With wake_chime on, "computah" "file an issue" still plays the cue before
  capture.