Feature request: native voice input (speak instead of typing prompts)

Summary

Request: native voice input for jcode — speak instead of typing prompts, with the audio transcribed to text and submitted the same way a typed message is today.

Motivation

Typing every prompt is slower than speaking for many users/workflows, especially for long free-form asks, brainstorming, or when multitasking away from the keyboard. Claude Code and several other agent CLIs/desktop apps already support this via OS-level dictation as a workaround, but a first-class in-app voice input would be more discoverable and could integrate more tightly (e.g. a mic button/hotkey right in the TUI/desktop input bar, streaming partial transcription, auto-submit on silence, etc.) rather than relying on the user to separately invoke macOS dictation.

Current state

Confirmed via source search that jcode has no STT/TTS/voice feature today:

• No "voice", "speech", "whisper", "microphone", "transcribe", "stt", or "tts" hits anywhere in crates/ or config.toml.
• The only current workaround is OS-level dictation (e.g. macOS Fn Fn dictation hotkey) typing into the same input box jcode already has — functional, but external to jcode and not documented/surfaced as a supported flow.

Proposed scope (rough, for discussion)

1. Input side (voice → text prompt):

   • A mic toggle (hotkey + button) in the TUI/desktop input bar.
   • Local or pluggable STT backend — e.g. whisper.cpp / OpenAI Whisper API / macOS's own Speech framework, configurable in config.toml similar to how provider/model routing works today.
   • Push-to-talk and/or silence-triggered auto-submit modes.
   • Should work on macOS to start (matches jcode's current primary platform); other platforms as a stretch goal.

2. Output side (optional, separate ask if wanted): TTS read-aloud of assistant responses — lower priority, could be a follow-up issue rather than bundled here.

3. Config surface: something like a [voice] section in config.toml (enabled, backend, hotkey, auto_submit_on_silence, etc.), consistent with how [display] and other sections are structured today.

Open questions for maintainers

• Preferred STT backend/dependency (local whisper.cpp for privacy + no network dependency, vs. a cloud STT API for lower resource use)?
• Should this live in jcode-tui only, or also the desktop2 app (given work is actively happening there per recent commit history — desktop2: a settings gear..., desktop2: more momentum... etc.)?
• Is a mic-button UI affordance in scope, or hotkey-only for a first cut?

Happy to help scope this further or pick up implementation if there's appetite — filing this primarily to get it tracked and gather maintainer input on backend/architecture preference before any code is written.

Start by reviewing the existing input and configuration areas under crates/ and config.toml, including the jcode-tui and desktop2 scope mentioned in the issue. Before implementation, get maintainer agreement on the STT backend, target interface, and whether TTS is excluded; done should mean a defined voice-to-text flow that submits prompts like typed input, with agreed configuration and platform coverage.