fix(voice): hold mic-mute window open until response stream ends

[MCERQUA]

Summary

When a streamed response includes multiple TTS chunks, the audio queue can briefly empty between chunks. With Groq Orpheus generation latency reaching 22-25s per chunk under load, the existing 800ms drain timer fired well before the next chunk arrived → STT resumed → mic captured the late-arriving TTS audio as user speech.

This PR extends playNextAudio()'s drain window to 30s while the response stream is still open (_streamingResponseActive = true). When the stream ends, finally{} clears the flag and collapses any pending long-wait drain back to the 800ms window so the mic returns promptly.

Incident

User report (2026-05-19, 1381-char response):

Response complete (1381 chars, LLM: 39679ms)
🔊 Playing TTS (TTS: 0ms)
🔊 Playing TTS (TTS: 0ms)
                              ← 22-second silent gap, mic went hot
🔊 Playing TTS (TTS: 22021ms)
🔊 Playing TTS (TTS: 22068ms)
🔊 Playing TTS (TTS: 22069ms)
...

Scope

Touches only ClawdbotMode in src/app.js:

• Constructor: declare _streamingResponseActive = false
• Stream start: set _streamingResponseActive = true immediately before fetch(?stream=1)
• playNextAudio() empty-queue branch: use 30000ms drain when flag is true, 800ms otherwise
• Streaming handler finally{}: clear flag + collapse pending long drain to short window

Untouched (and intentionally so):

• SpeechRecognition lifecycle in WebSpeechSTT.js (single instance, no destroy/recreate)
• VoiceSession.onSpeakingChange handler
• TTSPlayer queue ordering and AudioContext path
• PTT and wake-word flows
• _textDoneReceived interject guard

Rationale + monitoring checklist

docs/reference/voice-flow-mic-mute-drain.md (added in this PR) — symptom, root cause, why 30s, what to monitor post-deploy, rollback steps.

Rollback

Single commit. git revert 9c0952e restores prior behavior exactly (every drain falls back to 800ms; new flag remains declared but unused).

Risk

• If _streamingResponseActive ever leaks true after a stream ends, mic stays muted indefinitely → user mic appears dead. Guards: finally{} clears the flag unconditionally, plus the existing 60s INACTIVITY_TIMEOUT_MS will abort the request and trigger finally{} if the stream truly hangs.
• 30s is longer than any real-world inter-chunk gap observed so far. If Orpheus latency degrades further, the window may still empty; in that case the value can be bumped or made configurable, but a window > 30s starts approaching the inactivity timeout, so it's better to fix the generator.