fix(tts): lift mistralai blanket-ban behind opt-in gate (#34503)

[Bartok9]

Summary

• Lifts the runtime blanket ban on the mistral STT/TTS providers, which currently refuse unconditionally even for users on a verified-clean mistralai install.
• Gating is safety-first: re-enablement requires an explicit opt-in env var and a version floor, so the known-malicious 2.4.6 can never be re-enabled by this path.

Motivation

Closes #34503.

The mistralai PyPI project was quarantined on 2026-05-12 after the malicious 2.4.6 release (Mini Shai-Hulud). In response the runtime hard-blocked the mistral provider in both STT (tools/transcription_tools.py) and TTS (tools/tts_tool.py). The quarantine was version-specific — 2.4.8+ is clean — but the ban left users who manually verified a clean install with no escape hatch (silent "none" for STT, JSON error for TTS).

Rather than the issue's bare "check for credentials" approach (which would trust any installed version, including the malicious 2.4.6), this PR mirrors the repo's existing HERMES_ALLOW_PRIVATE_URLS opt-in pattern:

• New helper tools/lazy_deps.mistralai_unlock_status() -> (allowed, reason).
• Allows the provider only when both:
  1. HERMES_ALLOW_MISTRALAI is truthy (explicit user acknowledgment), and
  2. the installed mistralai is >= 2.4.8 (MISTRALAI_MIN_SAFE_VERSION).
• The version floor is enforced even when opted in — 2.4.6 is always refused.
• When locked, the user-facing messages now explain exactly how to re-enable.

tools/lazy_deps.py is the canonical home for the quarantine logic (it already documents the mistral quarantine and has version-checking helpers), so STT and TTS share one source of truth.

The mistral auto-detect skip in STT is intentionally left in place — only explicit provider: mistral selection is unblocked, keeping the change focused and avoiding surprising auto-routing to a paid provider.

Verification

• python3 -m pytest tests/tools/test_lazy_deps.py tests/tools/test_tts_mistral.py tests/tools/test_transcription_tools.py — 182 passed
• New TestMistralaiUnlockStatus (6 tests): locked-by-default, opt-in-but-missing, below-floor (2.4.6) refused, clean 2.4.8 allowed, newer allowed, falsey env stays locked.
• Updated STT/TTS dispatcher tests to the new contract: locked → none/error; unlocked + clean + key → routes to provider.
• Did NOT change: check_tts_requirements capability probe (a separate "is any TTS available" check, not part of the ban).

Notes

• Default behavior is unchanged for users who do nothing: the provider stays disabled. This is purely an additive, opt-in escape hatch with a hard version floor.

[Bartok9]

Closing as superseded by #34841 (3a2c03061, fix(stt,tts): restore mistralai — 2.4.8 is clean, ban lifted), merged on May 29.

My PR lifted the post-2026-05-12 mistralai quarantine behind an explicit HERMES_ALLOW_MISTRALAI opt-in gate + version floor (mistralai_unlock_status()). The maintainers took the cleaner route: the malicious 2.4.6 was removed upstream and clean releases resumed, so #34841 simply pins mistralai==2.4.8 for the tts.mistral/stt.mistral extras and restores normal lazy-install — the version pin itself is the safety mechanism, no env gate required. Rebasing my opt-in gate onto current main would re-gate a provider the maintainers have intentionally re-opened. Thanks!