A regional language tag no longer silences WebSocket TTS providers

Requesting a regional tag such as es-CO or es-MX forwarded the full tag to providers that accept only a base language. They rejected the request as invalid input, and because the streaming transports commit a 200 before the provider answers, the caller received a successful response carrying no audio.

Measured against the live API with identical text pinned to one provider: en and es each returned real audio, while es-CO and es-MX returned an empty 200 and the provider reported invalid input data. The tag now reaches these providers as its base subtag.

The region is not lost. Regional delivery is handled by the accent routing table, which pins a validated voice or supplies a steering instruction, and no WebSocket TTS provider is an accent primary.

This was reachable from the default route: a key whose policy language is a regional Spanish tag sent no language header and still resolved to an affected provider, so the documented quickstart body returned a successful response with no audio.

Both the buffered and streaming paths carried their own copy of these handshakes and both are fixed.

Action: No migration is required.