An accent tag no longer reduces the provider board to two candidates

Requesting a regional accent such as es-CO or es-MX left only the two providers named in that accent's table, so an explicit X-Speko-Allow for any other healthy provider returned 503 no_candidate and an accent request had almost no failover depth. An accent now orders the board instead of replacing it.

A TTS request carrying an accent tag removed every candidate whose wire protocol the accent table did not list. Measured against the live API, an accent tag cut the reachable TTS providers from 13 to 2, while the same key on es, es-419 or en reached all 13. Providers filtered out this way were healthy; the request never reached them.

The 503 reported only the caller's allow-list, deny-list, price cap and stage, so a rejection made by the accent read as a bad pin. The error now also reports the language actually routed on and, when the tag is an accent, the candidate chain that accent pins.

An accent's own candidate order reached selection as an exclusive filter rather than a preference. A chain therefore capped failover at its own length and, if every chain entry was unavailable, returned 503 instead of falling back to the ranked board. Chains from a key's routing policy had the same ceiling.

Ordered candidates are now a preference prefix: the accent's validated voice, or the key's policy chain, is still tried first, and selection continues into the ranked board behind it. An unpinned accent request resolves to the same provider it did before, now with the rest of the board behind it as failover.

GET /v1/routing/preview applied the same narrowing and continues to agree with the proxy, because both rank through the accent chain rather than filtering on it.

Action: No migration is required. Keys pinned to an accent gain failover depth they did not previously have, so a request that used to fail with 503 no_candidate may now be served by a provider further down the board. Pin explicitly with X-Speko-Allow to keep a request on one vendor.