fix(tts): retry transient /v1/audio/speech failures

[volschin]

Summary

A single 503 Service Unavailable from /v1/audio/speech dropped a whole response turn on a live call: TtsClient.synthesize raised through raise_for_status, VoicePipeline.synthesize_pcm16 logged the failure and returned empty, and process_turn_stream aborted with RuntimeError: TTS returned no audio. The caller heard nothing and got no spoken error. The next request seconds later returned 200 — the outage was brief enough that a bounded retry saves the turn.

Changes

• agent/tts.py — synthesize retries transient failures:
  • Retryable: RETRY_STATUS = 502/503/504, plus httpx.TransportError.
  • Not retryable: 4xx, and the 500 the server returns for a rejected request body — those repeat deterministically, so retrying only adds dead air before the same failure.
  • RETRY_BACKOFF_S = (0.3, 0.9) → 3 attempts, ≤1.2 s added in the worst case, so a retried turn still lands inside the caller's patience.
  • Each retry logs at WARNING, so recovered 503s stay visible for the still-open server-side root cause.
  • The backoff sleeps are asyncio.sleep cancellation points, so barge-in still cuts a retrying turn.
• TODO.md — marks the retry item done with the resulting policy; the "root-cause the server-side 503" item stays open.

synthesize_stream is deliberately untouched — /v1/audio/speech/stream is diagnostic-only and not on the production response path.

Testing

TDD — every test watched failing before the implementation existed:

• 503 then 200 → recovers, 2 requests
• transport error then 200 → recovers, 2 requests
• persistent 503 → raises HTTPStatusError after exactly 3 requests
• 500 → raises after exactly 1 request (no retry)
• cancelled mid-backoff → propagates CancelledError

Existing test_synthesize_raises_on_http_error retargeted 503 → 500, since 503 is now a retryable status.

venv/bin/pytest -q → 319 passed. ruff format --check / ruff check clean.