TTS audio overlaps when speak() is called before previous synthesis resolves

[ldstreet]

Summary

Toggling text-to-speech play/pause a few times on the same message (or rapidly clicking play on different messages) causes multiple audio streams to play simultaneously. The Stop control only cancels one of them, leaving the others audible until they finish.

Steps to reproduce

1. Open any chat with an AI reply.
2. Click the speaker icon to start TTS.
3. Click it again to stop.
4. Repeat the toggle a few times in quick succession.

Reproduced on both macOS and Windows 11 x64 (PR #520 build).

Expected

Only the most recent speak() request produces audio. Previous requests are aborted before their audio context starts.

Actual

Two or more audio streams play overlapped. Pressing stop only silences the most recently started one.

Root cause

frontend/src/services/tts/TTSContext.tsx speak() calls stop() synchronously, then awaits invoke("tts_synthesize", ...). During that await, a second speak() can start. Its stop() finds no source yet (the first hasn't created one), and both invocations eventually create their own AudioContext + BufferSource and call source.start(). The sourceNodeRef only holds one source at a time, so only the latest can be stopped.

Suggested fix sketch

Add an in-flight generation counter or AbortController in speak(). Before creating the AudioContext, check that this call is still the most recent; if not, bail without playing.