fix: respect configured/system lang in MCP instructions instead of hardcoding French

[danhayman]

I kept ending up with vox talking to me in French. I'd tell it to switch to English, I set lang en, the works — and it'd behave for a bit, then a session or two later French would quietly creep back in. After enough rounds of this I went digging, and the reason is that the MCP server's instructions blob hardcodes it:

- Use French by default (the user prefers it)

That string gets injected into the assistant on every initialize, so no amount of config ever made English stick. vox config set lang only changes the synthesis language, not the language the assistant actually writes its spoken summaries in — so the two never lined up.

This makes that one guideline come from the configured language instead, with a sensible fallback chain:

• lang is set → Speak in the user's language (<code>) — so French still works, you just vox config set lang fr
• no lang set → fall back to the system locale (e.g. fr_FR → fr), validated against SUPPORTED_LANGS
• nothing usable → Match the language the user is writing in (no language assumed)

I pulled the instruction-building into a small vox_instructions(lang) function and a normalize_locale helper so the logic is unit-testable, and handle_initialize resolves the language and passes it in. sys-locale is added for the system-locale lookup (works on macOS even when $LANG isn't set). I left the vox init output and its tests alone to keep the change focused.

Tests cover the configured-language formatting, the neutral unset fallback, and the locale normalization (fr-FR→fr, en_US→en, unsupported/empty → none). cargo test, cargo fmt --check and cargo clippy are all clean locally.