Interruptions don't clear GPT-Live audio that is already buffered locally #28

What

When you talk over GPT-Live, audio it has already sent may keep playing from the local buffers for a moment, because the helper's clear path is never triggered and wouldn't drop everything if it were.

Found while reviewing #25. It exists on main independently of that PR.

Details (as of main at 2f14174)

1. The clear is never sent. src/server/live.ts maps GPT-Live's output_audio_buffer.cleared event to { kind: "speech-cleared" }, but nothing handles that event, and HelperProcess.clear() (src/tui/helper.ts) is never called. So the helper's clear command (native/src/main.rs → Engine::clear_output) is unused.
2. A clear only empties the speaker ring. clear_output sets a flag the output callback uses to empty its ring (native/src/audio/io.rs, Renderer). RTP packets already queued for the engine, and decoded or resampled audio still in the engine, are not dropped, so they would play right after the clear.

Impact

Unverified. WebRTC delivers audio at roughly real-time pace, so the locally buffered amount is probably small: the jitter/prebuffer, likely tens to a few hundred ms. That means GPT-Live may run on briefly after you interrupt. Worth measuring before deciding how much to do.

Possible fix

• Route speech-cleared from the server to the terminal plugin and call HelperProcess.clear().
• Make the helper's clear drop everything downstream of the network: queued RTP packets, decoder/resampler state and output, and the speaker ring. Then resume with fresh audio.
• Keep playback bounded and resilient if the output device stops (see the review notes on fix!: preserve voice model selection and prevent PipeWire self-ducking #25 about pending-audio limits and waiting on the renderer).

Testing

A live call on macOS (and ideally Linux/Windows): interrupt GPT-Live mid-sentence repeatedly and check that it stops promptly, with no stale speech after it resumes.