fix(speech): wait for the new STT to be ready before replaying

[akirilyuk]

Symptom

With a speech backend that rejects new streams for about 30 s after it starts, a host that swaps the STT and calls releaseSttHold({ replay: true }) (or replayLastUtterance()) saw the replay stall in finalize and end with no final. When the stream finally opened, the queued audio was transcribed and the final came out as a plain user_speech_final, so hosts treated it as a new utterance.

Cause

The replay fed the held audio into the new STT before its stream was open. The single finalize wait (2 s) expired, the release completed without a final, and the replay context was gone by the time the late final arrived.

Change

• SttProvider::wait_ready(timeout) (default: always ready). The cluster STT shares a readiness signal between its stream task and the provider: true on Ready, false on every (re)open and when the task exits.
• release_stt_hold and replay_last_utterance wait up to SPEECH_STT_READY_WAIT_MS (default 15000) before feeding audio. On timeout they log and replay anyway.
• If release_stt_hold gets no final, the replay context stays armed so a late final is still flagged replay: true. A context older than 15 s is dropped, so a lost replay cannot mislabel a later utterance.
• The cluster STT logs a denied stream open once, then every 5 s, and logs the denied-attempt count when the stream opens.
• Docs and CHANGELOG updated.

Tests

• held_replay_waits_for_stt_ready, replay_ready_wait_times_out_and_continues, late_final_after_held_replay_is_flagged_replay, stale_replay_context_does_not_flag_later_utterance (speech crate).
• Readiness-watch test against the in-process mock server, and unit tests for the denied-open log throttle (cluster speech crate).

Verified locally and via CI; no extra manual steps.

🤖 Generated with Claude Code