feat(mcp): local MCP server exposes voicebox.* tools to AI agents

Mounts FastMCP at /mcp (Streamable HTTP) so Claude Code, Cursor,
Windsurf, and the VS Code MCP extensions can call voicebox.speak,
voicebox.transcribe, voicebox.list_captures, and voicebox.list_profiles
against the running Voicebox server.

Backend
- new backend/mcp_server package (tools, middleware, profile resolve,
  pub/sub events); named mcp_server to avoid shadowing the installed mcp
  PyPI package FastMCP imports internally
- app.py migrated from @app.on_event to lifespan= so FastMCP's session
  manager cohabits with Voicebox's startup/shutdown
- new MCPClientBinding table + /mcp/bindings CRUD; ClientIdMiddleware
  reads X-Voicebox-Client-Id into a ContextVar and stamps last_seen_at
- profile resolution precedence: explicit -> per-client binding ->
  capture_settings.default_playback_voice_id
- POST /speak REST wrapper for non-MCP callers (shell, ACP, A2A)
- GET /events/speak SSE broadcasts speak-start / speak-end so the pill
  surfaces agent-initiated speech
- backend/mcp_shim proxy (plain httpx) for stdio-only MCP clients
- PyInstaller spec updates + new --shim build target (~18 MB)

Frontend
- Settings -> MCP page with HTTP / stdio / claude-mcp-add copy snippets,
  default voice picker, per-client bindings table, connection status
- useMCPBindings, useSpeakEvents hooks
- CapturePill gains 'speaking' state; DictateWindow subscribes to SSE
  and emits dictate:show so the Rust side surfaces the pill window

Native
- tauri.conf.json externalBin now includes voicebox-mcp
- show_dictate_window helper + dictate:show listener in main.rs
- (also in this commit: InputMonitoringGate UX, hotkey_monitor tweaks,
  landing footer/navbar updates, new overview docs for captures /
  dictation / mcp-server / voice-personalities)

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

tauri/src-tauri/src/input_monitoring.rs

@@ -0,0 +1,82 @@
+//! Platform permission gate for the global keyboard tap.
+//!
+//! On macOS 10.15+, creating a CGEventTap that observes keyboard events
+//! requires the host process to be listed under System Settings → Privacy &
+//! Security → Input Monitoring. Without that trust, `rdev::listen` returns
+//! immediately and no key events ever flow through the chord engine.
+//!
+//! The relevant TCC pair lives in IOKit, mirroring `AXIsProcessTrusted` /
+//! `AXIsProcessTrustedWithOptions` on the Accessibility side:
+//!
+//!   - `IOHIDCheckAccess(kIOHIDRequestTypeListenEvent)` — read the current
+//!     grant without prompting. We call this from the Captures settings UI
+//!     so the row can show "granted" / "missing" without surprising the user.
+//!   - `IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)` — fire the
+//!     "Voicebox would like to receive keystrokes from any application"
+//!     dialog and add Voicebox to the Input Monitoring pane (toggle off).
+//!     Returns true when access is already granted; otherwise returns false
+//!     and queues the prompt. The user still has to flip the toggle on; this
+//!     just gets us into the list.
+//!
+//! `enable_hotkey` calls `request` on first invocation so the prompt fires
+//! from a deterministic, user-initiated point (the Captures toggle) instead
+//! of as a side-effect of `rdev::listen` creating its CGEventTap.
+//!
+//! Windows / Linux don't gate keyboard taps behind a TCC-style permission,
+//! so those branches return `true`.
+
+#[cfg(target_os = "macos")]
+mod ffi {
+    use std::os::raw::c_uint;
+
+    /// `kIOHIDRequestTypeListenEvent` from `<IOKit/hidsystem/IOHIDLib.h>` —
+    /// the request-type discriminator for "I want to read keyboard / mouse
+    /// events created by other processes."
+    pub const REQUEST_TYPE_LISTEN_EVENT: c_uint = 1;
+
+    /// `kIOHIDAccessTypeGranted` from `IOHIDLib.h`. The other values are
+    /// `Denied = 1` and `Unknown = 2`; we only ever care about the granted
+    /// case so they don't get their own constants.
+    pub const ACCESS_TYPE_GRANTED: c_uint = 0;
+
+    #[link(name = "IOKit", kind = "framework")]
+    extern "C" {
+        /// Returns the current access state as an `IOHIDAccessType` enum
+        /// (Granted=0, Denied=1, Unknown=2). No prompt side-effect.
+        ///
+        /// Declared as `c_uint` rather than `bool`: the C signature returns
+        /// the full enum, and reading a 3-valued enum into Rust's 1-bit
+        /// `bool` is undefined behaviour that silently inverts our gate.
+        pub fn IOHIDCheckAccess(request_type: c_uint) -> c_uint;
+
+        /// Returns true when access is already granted; otherwise queues
+        /// the system prompt and returns false synchronously. Safe to call
+        /// repeatedly — once the entry exists in the Input Monitoring pane
+        /// macOS won't re-prompt. Real `Boolean` (UInt8) return on the C
+        /// side, so `bool` here is correct.
+        pub fn IOHIDRequestAccess(request_type: c_uint) -> bool;
+    }
+}
+
+#[cfg(target_os = "macos")]
+pub fn is_trusted() -> bool {
+    unsafe { ffi::IOHIDCheckAccess(ffi::REQUEST_TYPE_LISTEN_EVENT) == ffi::ACCESS_TYPE_GRANTED }
+}
+
+/// Fire the Input Monitoring prompt if not already granted. Returns the
+/// current grant state; a `false` here means the prompt was queued and the
+/// user needs to flip the toggle in System Settings before key events flow.
+#[cfg(target_os = "macos")]
+pub fn request() -> bool {
+    unsafe { ffi::IOHIDRequestAccess(ffi::REQUEST_TYPE_LISTEN_EVENT) }
+}
+
+#[cfg(not(target_os = "macos"))]
+pub fn is_trusted() -> bool {
+    true
+}
+
+#[cfg(not(target_os = "macos"))]
+pub fn request() -> bool {
+    true
+}