Fix Voxtral TTS tokenizer dependency contract

[lyonsno]

Summary

• Remove silent fallback prompt path in Voxtral TTS that produced garbage audio when mistral-common[audio] was unavailable — replace with a clear RuntimeError
• Add mistral-common[audio] to the tts extra so the speech tokenizer is available in clean installs
• Add focused tests covering both the dependency declaration and the explicit runtime failure mode

Motivation

Voxtral TTS looked broken in clean .[tts] environments not because the model was bad, but because the integration silently fell back to a manual prompt-construction path when encode_speech_request(...) was unavailable. That fallback accepted the wrong prompt shape and produced garbage audio with no error. This makes the contract explicit.

Test plan

• python -m unittest mlx_audio.tts.tests.test_voxtral_tts -v — both tests pass
• Human smoke: BF16 and 4-bit Voxtral quants sound correct on Apple Silicon once the Mistral speech-tokenizer path is available
• Rebased on current origin/main — clean single commit

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[Blaizzy]

Please add this to test_models.py

[lyonsno]

Moved into test_models.py in 042355c.

[Blaizzy]

LGTM, just have nit

[lyonsno]

Moved the tests back to a standalone file — when the test class lives in test_models.py, the module-level mlx/numpy/misaki imports mean the contract test can't run in a minimal environment (it dies with ModuleNotFoundError: No module named 'mlx' before unittest even discovers the class). The standalone file only needs stdlib at import time, which is the whole point of a packaging-contract test.

Change implemented.

[lucasnewman]

@lyonsno Can we avoid adding a new dependency here?

[lyonsno]

@lucasnewman I don’t think we can safely avoid it in this PR. Voxtral TTS already depends on SpeechRequest / encode_speech_request from mistral-common[audio], and the old no-extra fallback was the path producing bad
audio. This change is just making the .[tts] install contract match the actual runtime requirement for Voxtral, and mistral-common[audio] is already present in our stt, sts, and all extras. If we want a
smaller install surface, I’d rather handle that as a follow-up by splitting Voxtral into its own extra instead of keeping a broken fallback in tts.

[lucasnewman]

@lyonsno Looks like the TTS tests are failing even though the mistral common package is being installed. Can you take a look?

[lyonsno]

I Took a look. The TTS failure was on an earlier PR head; I pushed follow-up fixes afterward, and the current head (af37164) is green now. Latest CI is passing.

[lucasnewman]

Thanks!