fix(desktop): allow WebKitGTK media permission requests so huddles work on Linux

[ryanrhughes]

Problem

Huddles have never worked on the Linux desktop app: starting one tears itself down about a second later. The mic never connects.

Root cause: WebKitGTK denies any permission request the embedder doesn't handle, and wry's WebKitGTK backend registers no permission-request handler (it implements media permissions only on Android and macOS — verified against wry 0.55.1 sources). So getUserMedia() always rejects on Linux → connectAndSetupMedia throws → cleanupFailedStart() ends the huddle. The open dictation PR (#1511) adds UI copy for "mic permission denied" — that's this bug's symptom.

Implementation

A small linux-media-permissions plugin in desktop/src-tauri/src/lib.rs: on webview ready, reach the native webkit2gtk::WebView via with_webview and connect permission-request, allowing exactly two request types:

• UserMediaPermissionRequest — mic/camera capture (huddles)
• DeviceInfoPermissionRequest — device labels for the input picker

Everything else returns false, keeping WebKitGTK's default deny — nothing beyond media devices is granted. Compiled out entirely on macOS/Windows.

Cargo.toml adds a Linux-only webkit2gtk = "2.0" dependency — the same crate + version Tauri already links (2.0.2 in the lockfile), needed only to name the types.

Testing

An automated test is impractical here: the behavior lives in a native WebKitGTK signal handler that requires a live webview under a compositor. Verified manually on Arch Linux (Hyprland/Wayland, webkit2gtk-4.1 2.52.4):

• Before: start huddle → mic never connects → huddle drops after ~1s, every time.
• After: start huddle → mic connects, huddle stays up, audio works.

Manual test steps: on any Linux machine, build the desktop app, join a community, start a huddle in a channel. Without this patch it self-ends within ~2s; with it, it stays connected.

Checklist

• just ci: all gates pass except buzz-db unit test replica_fence::tests::fence_starts_closed_and_opens_on_advance, which fails identically on pristine main (timestamp precision mismatch: …237894Z vs …237894147Z, last touched in Route lag-tolerant reads to an optional Postgres read replica #2084) — pre-existing and unrelated; happy to file a separate issue.
• Integration tests: N/A — no relay/db/auth changes.
• No new unwrap()/expect() in production paths; no unsafe.
• No new public API surface to document; behavior is documented in code comments.