Allow superseded audio replies to be aborted

[cubrift]

Problem

The audio response path creates an AbortController and uses it for transcription, but the subsequent openai.chat.completions.create call that generates the TTS response does not receive the controller signal.

When a new message arrives for the same chat, Quart aborts the active controller, but an in-flight audio generation can continue and send stale audio after the newer message has started processing.

Expected behavior

Audio transcription and audio response generation should both stop when their controller is aborted.

Suggested direction

Pass the controller signal using the OpenAI request options supported by the current client, and check the signal before sending the generated audio.

Acceptance criteria

• A superseded TTS request receives the active abort signal.
• Aborted audio generation does not send stale audio.
• Presence is returned to paused after cancellation.
• Normal audio replies still send exactly one audio message.

[hgshreyas]

I'd like to take this issue. My plan is to pass the active AbortController signal to the OpenAI TTS request, check for cancellation before sending the audio, and ensure presence is restored to paused on abort.

[cubrift]

Great plan @hgshreyas.