feat: pick the transcription model from a configured language

[00Ssam00]

Parakeet v2 is English-only, and it fails silently on everything else. It doesn't reject Spanish audio — it forces it through English phonetics and writes a plausible transcript with no error and no warning. Someone who doesn't speak the language of the meeting has no way to catch it.

FluidAudio 0.15.5 is already pinned in Package.resolved, and it already ships AsrModelVersion.v3 — multilingual across 25 European languages. transcribe(_:decoderState:language:) takes the language hint as an optional third argument, so the existing call site compiles against v3 unchanged. This is configuration, not integration.

What changes

One knob in the transcription block that already exists:

{ "transcription": { "enabled": true, "engine": "parakeet", "language": "en" } }

It selects the model, not just a hint:

language	Model
"en" (default)	Parakeet v2 — better WER on English
any of the other 25	Parakeet v3 + script hint
"auto"	Parakeet v3, no hint

"en" stays the default deliberately: it preserves today's behaviour exactly and doesn't push a second ~600 MB download on anyone who never asked for another language — the same reasoning that made echo cancellation opt-in in 8ab6ebb.

The three languages FluidAudio's Language enum knows but v3 isn't trained on (bs, be, sr — the enum partitions scripts, not model coverage) still run, but warn on stderr. An unknown code warns and falls back to English rather than transcribing with a model nobody chose. A wrong-language transcript arriving unannounced is the exact failure this setting exists to prevent, so nothing here is silent.

No UI. A meeting's language is a property of the user, not of the meeting, and a picker would require Config to write — the first persistent state the app owns. quill doctor already reports whether the selected model is cached, so it now parameterizes the version instead of pinning .v2.

Evidence

Same 12.4 s of Spanish (say -v "Mónica", es_ES) down both paths.

v3:

Buenos días a todos, como veis la migración del pipeline de transcripción. Creo que deberíamos añadir suporte multilingüe cuanto antes, porque el modelo actual solo entiende inglés, y eso es un problema serio para nuestras reuniones en español.

Two errors in ~40 words.

v2, same audio:

How is the migration of the people in transcription? I think that we have a support of multilingual […] because the model actual zoning and less, and that is a problem for our union in Spanish.

transcribe.log recorded done — 2 segments. No error, no warning, well-formed transcript.md.

Also verified: language → model mapping across all 29 possible values; separate caches (v2 452 MB, v3 470 MB) coexisting; provenance recording the model that actually ran; v3 loading an 8192-token vocabulary against v2's 1024.

One nuance worth knowing: on Spanish audio v3 emits no ¿/¡ at all and closes questions with . rather than ?. Segmentation still breaks correctly, just on the period — the doc comment now says so.

What is not verified

v3's quality on real meeting audio — noise, overlapping speech, varied accents. The test above uses clean TTS, which says nothing about any of that. v3 traded some English accuracy for multilingual coverage, and that trade is unmeasured here. It's why feat-001 is filed as implemented rather than done, and why the default stays on v2.

Full write-up, including the rejected design alternatives and a few unrelated code observations, is in .issues/feat-001-multilingual-transcription.md.