[功能]: 添加 MiniMax TTS 和 STT 提供商系列 (T2A v2 + speech_to_text)

MiniMax is already a supported **chat** provider (`zeroclaw providers` lists `minimax`; `MinimaxModelProviderConfig` carries `endpoint: cn | intl` and a `uri` override). It has no TTS or STT family: - TTS families today: `OpenAI`, `elevenlabs`, `google`, `edge`, `piper` - STT families today: `groq`, `OpenAI`, `deepgram`, `assemblyai`, `google`, `local_whisper` So anyone using MiniMax speech — a vendor with 300+ system voices across 40 languages, including explicit Cantonese support — must run an out-of-tree HTTP proxy that impersonates an OpenAI endpoint and translates the wire format. That is what I am doing today, and it is a lot of surface for what should be a provider entry. Two concrete consequences of the gap, both hit in practice: **1. Cantonese TTS is unreachable through the OpenAI shim.** MiniMax only produces Cantonese phonology when the request carries `language_boost: "Chinese,Yue"`. There is no OpenAI field that maps to it, so the shim must invent one and infer it from the voice id. Worse, MiniMax's *legacy* endpoint (`POST /v1/text_to_speech`, flat body) silently returns **Mandarin** for the same voice + boost combination, so a shim that guesses the endpoint wrong produces plausible-sounding wrong language with no error. Getting this right is provider knowledge, not something a generic OpenAI-compatible client should have to encode. **2. Cantonese STT cannot be requested at all.** MiniMax's `language` is a **request header** (`zh` / `yue` / `en` / `ja` / …), not a body field — and neither `OpenAiTranscriptionProviderConfig` nor `OpenAITtsProviderConfig` exposes an `extra_headers` field (model providers do: `AnthropicModelProviderConfig` has one). So `yue` is unsettable through the existing families, and the transcription silently falls back to auto-detect. For a Telegram bot receiving Cantonese voice notes this is the difference between a correct transcript and a Mandarin one.