fix: continue recording after barge-in interrupts TTS

[aydiler]

Summary

• Barge-in detection works correctly (TTS stops when user speaks), but the captured audio buffer is only ~0.5s — whatever was recorded during TTS playback before the interrupt fired
• The current code skips normal recording when barge-in occurs, so everything the user says after TTS stops is lost
• STT receives a tiny audio snippet and produces nonsensical transcriptions ("are.", "This.", "Bye.")

Fix

After barge-in interrupts TTS, continue recording with silence detection (same as normal flow, but skip the pause and chime since the user is already speaking). Prepend the barge-in buffer to the continuation audio before sending to STT.

Before: ~5-7KB audio, gibberish transcription
After: ~100-130KB audio, correct transcription of full sentence

Test plan

• Call converse with a long message, interrupt by speaking mid-TTS
• Verify TTS stops promptly (<50ms)
• Verify recording continues after TTS stops until silence detected
• Verify full sentence is transcribed correctly
• Verify non-barge-in flow (wait for TTS to finish, then speak) still works

[ai-cora]

Thanks @aydiler — this is a clean, correct fix for the truncated-buffer problem (only the ~0.5s pre-interrupt buffer was reaching STT). The catch is it's stacked on the barge-in feature branch (#238 / VM-606), which hasn't landed on master yet, so #281 can't merge independently. Let's land it as part of #238 rather than separately — would you be up for folding this commit into that PR (or rebasing onto master once #238 merges)? The continue-recording + prepend-buffer approach is exactly right and we want it in the box.