fix(audio): send Xiaomi MiMo TTS audio.format as the mp3/wav enum

[LazyGatto]

Summary

• Xiaomi MiMo TTS (POST /v1/audio/speech, mimo-v2.5-tts) failed upstream with 400 Param Incorrect for every response_format. The upstream body field audio.format was populated with an IANA media type (audio/mpeg / audio/wav) instead of the mp3 | wav enum the MiMo chat-completions audio API requires.

Related Issues

• Closes fix(speech): Xiaomi MiMo TTS rejects every response_format — audio.format sent as an IANA media type instead of the mp3/wav enum #15751
• Related to #

Validation

• Change type: provider
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR
• SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

Tests Added Or Updated

• tests/unit/audio-speech-handler.test.ts
  • updated the existing Xiaomi MiMo payload assertion (audio.format: "audio/wav" → "wav") — it encoded the bug;
  • new regression: omitted response_format must send the enum "mp3" (never an IANA media type);
  • new regression: invalid response_format (ogg) returns 400 without calling upstream.
• 28/28 pass with the fix; reverting open-sse/handlers/audioSpeech.ts makes exactly the 2 MiMo tests fail.

Coverage Notes

• This changes open-sse/handlers/audioSpeech.ts; the new unit tests cover normalizeXiaomiMimoRequestFormat() (enum mapping, default, rejection) end-to-end through handleAudioSpeech with a mocked fetch. Coverage does not move down.

Reviewer Notes

• normalizeXiaomiMimoMimeType() is kept unchanged and is still the source for the response Content-Type; only the audio.format request field switches to the enum. Invalid response_format still returns 400 before any upstream call.
• pcm / pcm16 remain unsupported (out of scope; the client-facing 400 message is unchanged).
• check:open-sse-typecheck fails on open-sse/services/apiKeyRotator.ts (TS2484) on a clean release/v3.8.52 checkout as well — pre-existing, untouched.
• Changelog fragment is added; it will be renamed with the PR number in a follow-up commit.

[LazyGatto]

CI note: the failing checks in this run are pre-existing drift on release/v3.8.52, not caused by this diff. Happy to rebase once the base is green.

Evidence:

• API Route Typecheck fails with open-sse/services/apiKeyRotator.ts TS2484 (baseline 0, live 1) — that file is not in this diff, and the exact same failure occurs on release/v3.8.52 itself (run 37681442713) and on other branches (fix/handler-rejection-call-log, fix/streaming-concurrency-limit, docs/systemd-watchdog, …).
• The remaining failures are the same repo-wide drift everywhere: stale doc counters (Docs Sync / Docs Gates, 10 STRICT drifts), orphan test discovery (Lint), generated agent-skills sync (Merge integrity), scheduled-job guard in docker-publish.yml (Quality Gates Extended), feature-flag count 82 !== 81 and related assertions (Unit shards), MCP audit test timeouts (Vitest), and playwright-core node-builtins in the client bundle (Build).
• This PR's own changes are green in CI: all 4 audio-speech-handler tests pass (including the two new regressions), [changelog-integrity] OK — no base bullets lost vs origin/release/v3.8.52, semgrep / Change Classification / PR Test Policy pass.

Scope stays minimal: enum fix + tests + changelog fragment — no baseline widening, no unrelated fixes.