fix(tts): never truncate spoken replies — split long text and scale playback waits

[andrexibiza]

Related #17973 #53587 #53589 #75201

What changed and why

The streaming-TTS truncation class had four silent user-facing failure modes on main:

1. 4000-char pre-cap in speak_text and cli._voice_speak_response — every voice-mode/TUI reply was sliced to 4000 characters before synthesis, so long answers were cut off mid-sentence (#53587).
2. Provider-level truncation in text_to_speech_tool — over-cap text was truncated to the per-provider request limit (OpenAI 4096, xAI 15000, MiniMax 10000, …) with only a log line, silently dropping the tail of user-facing speech (#17973).
3. Streaming per-sentence truncation — a single sentence over the provider cap was sliced (cleaned[:stream_max_len]) in stream_tts_to_speaker, losing the end of run-on replies.
4. Flat 300s ffplay wait — play_audio_file killed ffplay after 300 seconds, cutting long TTS files mid-playback even when synthesis succeeded.

The fix

• No arbitrary truncation: speak_text and _voice_speak_response now pass the full prepared text; length enforcement is deferred to the provider layer, which now splits instead of truncating.
• Split long speech: text_to_speech_tool splits over-cap text into provider-safe chunks (sentence-boundary aware; run-on words hard-sliced so no content is ever dropped) and concatenates the per-chunk audio with ffmpeg into the single requested output file. Without ffmpeg it degrades to the first chunk with a loud warning (never worse than the old behavior).
• Streaming path: an oversized sentence is split into cap-sized parts, each prefetched in order, so run-on replies are spoken in full.
• Waits scaled to content: play_audio_file probes the file duration (ffprobe) and waits duration + 30s slack instead of a flat 300s cap.
• websockets v15: the xAI streaming TTS path passes additional_headers (the extra_headers kwarg was removed in websockets 14/15 — this path was crashing on every streaming xAI synthesis).

How to test

# Targeted suites (from repo root with the project venv)
python -m pytest tests/tools/test_tts_streaming.py \
  tests/tools/test_tts_streaming_e2e.py \
  tests/gateway/test_streaming_tts_consumer.py \
  tests/gateway/test_streaming_tts_gateway_regression.py \
  tests/tools/test_tts_max_text_length.py -q --no-header -p no:cacheprovider

# New regression coverage (all pass):
#  - test_split_text_for_tts_*            : splitting never drops content
#  - test_text_to_speech_tool_splits_long_text_and_concatenates : 5000 chars → [4096, 904], temp cleanup
#  - test_speak_text_no_longer_precaps_at_4000 : full 5000-char reply reaches the provider layer
#  - test_hybrid_oversized_sentence_split_not_truncated : 200-char sentence with 40-char cap → 5 parts, joined == original
#  - test_ffplay_wait_scales_to_file_duration : wait == duration + 30s slack
#  - test_xai_websocket_uses_additional_headers : websockets v15 kwarg

# Manual smoke (optional, with a TTS provider configured):
#   speak_text("…a 5000+ character reply…") in the TUI voice loop should now speak to the end.

Expected: all of the above pass except the known pre-existing timing-flaky test_hybrid_prefetch_fires_http_immediately (fails on pristine origin/main too — it's an environment-timing test, not related to this change; verified against a clean checkout).

Platforms tested

• Windows 10 (git-bash), CPython 3.11 — full targeted suites green.
• ffmpeg/ffprobe present (Windows path); the no-ffmpeg degrade path is covered by the fallback branch and unit-tested via mocked concat.

Why this matters to users

Voice mode and TUI TTS used to silently stop reading long replies at 4000 characters, drop the tail of anything over the provider's request cap, cut playback at 300 seconds, and crash xAI streaming entirely under websockets v15. After this change, whatever the model says is spoken in full — split into provider-safe chunks and reassembled — and playback waits as long as the audio actually is.

Credits

• Splitting + chunk concatenation approach salvaged from #17973, authored by @TKCen.
• 4000-char cap removal + ffprobe-scaled ffplay wait salvaged from #53589, authored by @Nomadcxx.
• websockets v15 additional_headers fix salvaged from #75201, authored by @pluton74mac.

Fixes #53587
Fixes #17973

Part of #40010
Part of #78207
Part of #79890

[andrexibiza]

CI failures (slices 2/8 + 7/8) — root-caused and fixed (8e86264ea6)

Both failures came from the #53587 duration probe interacting with tests that mock subprocess.Popen:

• test_play_audio_file_scrubbed_env — subprocess.run (the probe) internally calls the mocked Popen, so the probe's env-less call overwrote the test's captured player env (env=None → assertion fail). Fix: the test now identifies the system-player call by its flags (-nodisp/-autoexit) instead of assuming a single Popen call.
• test_play_audio_file_skips_sounddevice_on_macos — the fake proc lacks stdout/stderr, so the probe raised AttributeError, which the outer handler misread as "player failed" and aborted a successful playback. Fix: the probe catches Exception broadly — best-effort by contract, it can never raise or affect playback.

Windows-local failure class — closed (277693ee42)

The 6 tests that fail on a Windows host (deterministic, verified identical on pristine main) are all in the repo's documented platform-mock/timer class:

Test	Root cause	Fix
TestPulseSocketReachable ×2	socket.AF_UNIX doesn't exist on Windows Python	skipif(win32) — feature is POSIX-only
test_wsl_without_pulse_blocks_voice	Windows has real powershell.exe, so the PowerShell TTS fallback is "available" and the code correctly downgrades to a notice	pin _wsl_powershell_tts_available → False (the scenario under test)
TestWSL2PowerShellFallback ×2	fallback gated on platform.system() == "Linux" (WSL IS Linux) but tests only mocked _is_wsl2_env	patch platform.system → "Linux" (repo's documented sys.platform/platform.system pattern)
test_hybrid_prefetch_fires_http_immediately	time.monotonic() ~15.6ms tick on Windows; prefetch-adjacent starts land on the same tick	record with time.perf_counter() (QPC, high-res)

Verification

• Both files: 111 passed, 2 skipped (the PulseSocket guards) on Windows.
• Full campaign voice surface (14 files, incl. transcription_tools, wake_word, stt, gateway streaming): 300 passed, 2 skipped.
• The one remaining local failure (test_stderr_progress_extends_beyond_timeout) is the pre-existing timing test fixed by test(stt): stabilize idle-timeout progress test against spawn latency (pre-existing flake on Windows + loaded CI) #78221 (already open, CI-green) — this branch picks it up when it merges main.

CI is re-running on the new head (277693ee42).