Streaming TTS reaches every provider that can stream, including the regional-accent voices

POST /v1/audio/speech/stream and POST /v1/synthesize/stream could only be served by the four providers with a WebSocket TTS surface. Seven more already answer with progressive raw PCM over HTTP, and two of them carry the validated regional Spanish voices, so an accent tag could never reach its own voice on a streaming route.

The streaming routes now select across every provider whose response is already progressive PCM, ranked by the board, and serve it through the same engine the buffered routes use. That engine was forwarding those providers chunk by chunk all along; only the streaming routes' candidate filter hid it.

A regional Spanish tag now resolves to its own voice on a streaming route. Verified locally against the live providers: es-CO resolved to ElevenLabs and es-PR, es-CU and es-MX to Cartesia, each arriving chunked with the first bytes between 283 and 1186 ms.

A key whose routing policy pins a TTS chain still has that chain outrank the accent order, which is unchanged and deliberate. Accent order applies when the key carries no TTS chain.

Providers reached only over WebSocket TTS are unaffected: a request pinned to one of them is still served by the WebSocket engine, so existing pins keep working.

A request that can only reach a provider which returns one finished blob is refused with 503 no_streaming_tts_provider naming the constraint, rather than served as a response whose body arrives all at once. response_format other than pcm is still refused with 400.

The WebSocket ready frame now carries routeReason, the selection explanation the upgrade could not send as a header.

Action: No migration is required. A caller that pinned a WebSocket provider to obtain streaming can drop the pin and let the board choose.