demo: reset stale mimi streaming state before generation

[abePclWaseda]

Symptom

When running liquid-audio-demo behind a tunnel/TURN relay, the chat would respond to the first utterance and then hang forever: no reaction to any later turn, no error in the UI.

Root cause

chat_producer opens mimi.streaming(1) for each generation. If a turn is interrupted mid-generation — we hit this reproducibly via fastrtc's hardcoded 60-second frame-processing timeout (Timeout in frame processing cycle after 60 seconds - resetting) — the streaming context is left open. The next chat_producer call then dies in its worker thread with:

Exception in thread Thread-8 (chat_producer):
AssertionError: is already streaming!

Since the exception happens in a background thread, the consumer in chat_response blocks on the queue forever and every subsequent turn fails silently, which makes the whole session look frozen.

Fix

Reset stale streaming state at the start of chat_producer (mimi exposes is_streaming / reset_streaming() for exactly this), so a single interrupted turn cannot wedge the session.

Testing

• Verified the multi-turn state-machine path (system prompt → add_audio → generate_interleaved → chat.append → next turn) for 3 consecutive turns with this guard in place on an A100, including with LFM2.5-Audio-1.5B-JP.
• Before the patch, one interrupted turn reliably produced the is already streaming! traceback above and froze the demo; after the patch the next turn recovers.
• ruff check / ruff format --check pass.