Implement Multilingual Support

[mchl7852]

Presently our system only supports English. To enhance its usability we should add support for multiple languages - and the app is not merely inconvenient in another language, it is wrong.

Language in src/renderer/types/config.ts has exactly one member:

export enum Language {
  English = 'en',
}

RuntimeConfig.language defaults to 'en' and is read by nothing. It is not sent on any request, it is not on the ASR WebSocket URL, and no control surfaces it. A candidate interviewing in Spanish gets an English speech model transcribing Spanish audio - which does not error, it returns confident English words that were never said - and then a suggestion answering the question that mis-transcription invented.

What to add

Make language a real setting and thread it through the three places that decide what language the session runs in.

• Fill out Language (see the set below) and give it display metadata: English name plus endonym, since a user who has the app in the wrong language recognises "Deutsch" faster than "German".
• A Language control on the control bar, next to Audio and Model - it shapes the input (which speech model transcribes) and the output (what language suggestions come back in), so it belongs with the other two session inputs rather than with the presentation toggles.
• language on the live, action and summarize request bodies.
• ?language= on the ASR streaming WebSocket URL.

The language set

Six: English, Spanish, German, French, Portuguese, Italian. That is what AssemblyAI's universal-streaming-multilingual model covers, and offering a language in the picker that the transcription cannot deliver would be worse than not offering it.

Details that decide whether this is usable

• The control has to work mid-interview. An interview that switches language is the case this exists for, and it is not one the candidate can prepare for by restarting. The two halves move at different speeds: suggestions follow immediately, since every request reads the setting as it is built, while the ASR carries its language as a connection parameter and has to reconnect both channels. So the button reports the wait rather than pretending the change was instant, and the menu says what will happen before the user commits - a two-second hole in the transcript is alarming if it arrives unannounced mid-question.
• A reconnect must not leave two sockets on one channel. The existing ws.onclose path schedules a backoff reconnect on any unexpected close, and a deliberate close for a language switch looks exactly like one. Whichever socket loses that race stays open and keeps relaying audio into a dead session.
• The current language has to be readable without opening anything. A globe icon alone means the control is only useful to someone who already knows what it is set to; the bar shows the code (EN, ES) next to it.
• A stored language the build no longer knows about must fall back to English, not be sent verbatim to the backend and the ASR.
• A client that sends no language must keep working. The field is defaulted on the backend, so the wire stays backward compatible in both directions.

Not in scope

Localising the app's own chrome - buttons, labels, dialogs, toasts. That is a separate feature with a separate cost (roughly 45 components and every main-process error string), and it is not what makes the product unusable in Spanish today: an English button on a Spanish interview is an inconvenience, an English transcript of Spanish speech is a wrong answer read out loud. This ticket is the second one.

[alpha5611331]

Review pass over the multilingual feature is done - 11 fixes pushed to feat/multilingual-support and written up on #108.

Highest-severity find: interviewer questions in a non-Latin script were still being dropped outright when the turn opened on a Latin loanword (OK、では次の質問です。 normalizes to exactly ok, which the backchannel lexicon then consumes). That is the same silent failure the earlier fix addressed, one branch further in, and it affects Japanese, Korean, Chinese, Russian, Greek, Arabic, Hebrew, Thai and Hindi.

Also fixed: the transcript merge separator rewriting the whole session's spacing on a mid-interview switch, an orphaned ASR socket leaked by two overlapping switches, no text direction anywhere for Arabic/Hebrew, the sentinel failing to match behind a directional mark, and the exported report being half-translated.

One thing left open for a decision, since it needs a protocol change across both repos: nothing detects backend/client language drift, so a language the client offers and the backend does not resolves silently to English while the picker shows it as selected. Details on #108.