feat: voice dictation to the chat composer

[BartSu]

What

Adds voice input to the chat composer. A mic button next to the attach button dictates into the draft using the browser's own Web Speech API — no API key, no backend endpoint, and no audio passing through orx. Only ui/ changes; the Rust side is untouched.

Interim words appear in the field as they are heard and are rewritten in place until the phrase settles.

How

ui/src/useDictation.ts (new) wraps SpeechRecognition:

• Language follows the UI locale (en → en-US, fa → fa-IR, zh-CN as-is); switching it restarts the recognizer in place.
• Insertion is anchored where listening began, and re-anchors at the caret whenever the field no longer holds what we last wrote — so typing and speaking interleave without either clobbering the other. Results already shown become part of the user's text, and later revisions of them are dropped rather than painted twice.
• Idempotence: each event rebuilds the text from the session's result list instead of appending to it, so an engine that re-delivers results it already settled (Safari) cannot double a phrase.
• Continuity: Chrome ends a session on silence, so sessions restart automatically. A strike budget gives up on a recognizer that keeps ending the instant it starts, instead of spinning on start/end.
• Spacing is decided in one place (joinHeard) for all three boundaries: existing draft ↔ dictation, settled ↔ interim, and across a session restart, where the first transcript does not lead with a space.

ui/src/components/ChatPanel.tsx:

• Mic button with three states — idle, listening (red, pulsing), and unsupported (visible but disabled, with a tooltip naming the browser requirement, since there is nothing actionable on Firefox).
• The button declines focus on mousedown, so a caret placed mid-message survives the click.
• Errors the user can act on (mic blocked, no device, offline) surface above the composer; no-speech and aborted are normal and stay silent.
• send() and runShell() stop listening.
• Dictation writes through the same setDraft path as the keyboard, so skill chips, the slash menu, and send need no special case.

New message keys are added to all three catalogs (en, zh-CN, fa).

Privacy note

Chrome's Web Speech implementation sends audio to Google's recognition service; Safari sends it to Apple's. This is worth knowing given the project's local-first framing — nothing is routed through orx itself, but the audio does leave the machine via the browser. Happy to add a line to the settings UI saying so, or to swap in a local engine later, if you'd prefer.

Testing

• node ui/scripts/check-i18n.mjs, node ui/scripts/check-styles.mjs, pnpm typecheck, pnpm build, and the 162 UI unit tests all pass.
• ui/dist is regenerated and committed.
• The recognition path was driven end-to-end in the running dashboard with a stubbed SpeechRecognition, covering: interim rewritten in place, phrases settling, new phrases appended, session restart continuity and its word boundary, re-delivery of settled results, typing before the first result, typing mid-phrase followed by that phrase settling, and stop/start.
• The live path was also confirmed against the real recognizer in Chrome (start, focus, stop), though transcription accuracy itself was not measured.

[BartSu]

Could a maintainer please approve the GitHub Actions workflows for this PR? The required checks are currently waiting for approval.