Linux: huddles fail with NotAllowedError — WebKitGTK user-media permission request appears unhandled

[scottsanpedro]

With the WebRTC GStreamer plugins loading correctly (see #3494)
and a working audio input device present, starting a huddle on Linux fails with:

The request is not allowed by the user agent or the platform in the current
context, possibly because the user denied permission.

No permission prompt is ever shown.

On macOS/Windows the OS provides the mic-permission UI, but on Linux WebKitGTK the
embedding application must answer WebKitUserMediaPermissionRequest (via the
permission-request signal / wry's permission hook) — an unanswered request is a
denial. I can't find a handler for this in the desktop shell, which would make
getUserMedia structurally un-grantable on Linux regardless of hardware.

Diagnostic ladder ruled out (Arch, native 0.5.0):

1. GStreamer webrtc/nice plugins load (after the bundled-lib workaround above);
2. an audio source is present and enumerable (verified with a PipeWire source;
   with no source present the error is a constraint error instead, as expected);
3. the failure is then NotAllowedError with no prompt → permission layer.

Suggested fix: handle WebKitUserMediaPermissionRequest in the Linux WebView
(allow for the app's own origin, or surface an in-app prompt), and ideally also
webkit_settings_set_enable_media_stream(TRUE) if not already set.

Happy to test a build — this is the last blocker for voice on native Linux as far
as I can tell.

Environment: as #3494.

[dekanbro]

Confirmed on a second Linux distribution with the same failure.

Environment:

• Ubuntu 24.04 (Noble), GNOME Wayland
• Buzz Desktop 0.5.0 native build
• PipeWire 1.0.5; pipewire, pipewire-pulse, and WirePlumber all active

Behavior:

1. Starting a huddle creates the huddle lifecycle entry.
2. It immediately rolls back to Huddle · Ended — 1 participant.
3. No microphone permission prompt is shown.
4. The UI reports: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

Local diagnostics:

• PipeWire sees Buzz playback routed to the active speaker.
• A working internal digital microphone is present and selected as the live default source.
• GStreamer pulsesrc, pipewiresrc, and autoaudiosrc plugins are available.
• No Buzz microphone capture stream appears when the huddle attempt fails.

This matches the unhandled WebKitGTK user-media permission-request diagnosis and shows the problem is not Arch-specific.