Linux desktop: WebKitWebProcess segfaults in PipeWire's module-metadata on startup (device enumeration, no huddle join needed)

### Environment

- Arch Linux, KDE Plasma / Wayland
- Buzz 0.5.3 (`Buzz_0.5.3_amd64.AppImage`, extracted AppDir install)
- pipewire 1.6.7, gst-plugins-bad/good 1.28.5, webkit2gtk-4.1 (bundled)

### Symptom

Shortly after launching Buzz (roughly 40-60s in, **no huddle join required**), `WebKitWebProcess` segfaults and the whole renderer dies. The main `buzz-desktop` process and `WebKitNetworkProcess` stay alive with no renderer to draw the window, so from the user's side it looks like a freeze rather than a crash — no dialog, just a dead window.

Reproduced 3 times with an identical fault signature (2 historical + 1 fresh repro today), and this specific top-of-stack shape (pipewire/protocol-native) appears in all 19 `WebKitWebProcess` coredumps logged since 2026-07-17.

### Not the known #3494 issue

This is not the bundled `libsoup`/`libnghttp2` AppImage-shadowing bug (#3494) — that workaround (renaming the bundled libs, clearing the GStreamer registry cache) is applied here and does not prevent this crash.

### Symbolized backtrace

Via `coredumpctl debug --debugger=gdb -A "-batch -ex 'thread apply all bt' -ex quit"` with Arch's debuginfod:

Main WebProcess thread — blocked waiting on device enumeration, called directly from WebKit:

```
Thread N (main thread):
#0 ... pthread_cond_wait () from libc.so.6
#1 ... from /usr/lib/spa-0.2/support/libspa-support.so
#2 ... from /usr/lib/gstreamer-1.0/libgstpipewire.so
#3 gst_device_provider_start () from libgstreamer-1.0.so.0
#4 ... from libwebkit2gtk-4.1.so.0
```

The PipeWire client's own main-loop thread — this is the one that actually dies:

```
#0 0x0000000000000003 in ?? ()
#1 ... from /usr/lib/pipewire-0.3/libpipewire-module-metadata.so
#2 ... from /usr/lib/pipewire-0.3/libpipewire-module-protocol-native.so
#3 ... from /usr/lib/pipewire-0.3/libpipewire-module-protocol-native.so
#4 ... from /usr/lib/spa-0.2/support/libspa-support.so
#5 ... from libpipewire-0.3.so.0
```

Frame #0 is a call through literal address `0x3` — a corrupted/uninitialized callback pointer, not a normal bad-pointer bug. Every neighboring frame resolved cleanly via debuginfod, so this isn't a missing-symbols artifact — it's a genuine wild jump.

Kernel log corroborates on two occurrences:
```
segfault at 3 ip 0000000000000003 ... error 14
Code: Unable to access opcode bytes at 0xffffffffffffffd9.
```

### What this looks like

WebKit's media-device enumeration (`gst_device_provider_start()`, presumably triggered automatically by a camera/mic-capable UI element on load rather than requiring an explicit huddle join) opens a PipeWire client connection. On that client's own main-loop thread, something invokes a metadata-change callback (`libpipewire-module-metadata.so`) through a garbage function pointer, killing the process. `GST_DEBUG=3` shows nothing before the crash — it happens entirely inside PipeWire's client code, below GStreamer's own error/message reporting, which is presumably why this hasn't surfaced as a catchable GStreamer error anywhere.

### Reproduction

1. Launch the 0.5.3 AppImage (extracted) on Arch with pipewire 1.6.7.
2. Wait ~40-60s without interacting with any huddle/call UI.
3. `WebKitWebProcess` segfaults; `buzz-desktop` and `WebKitNetworkProcess` remain running with a dead window.

Happy to provide the full symbolized backtrace/coredump or test further if useful — this looked like it might also be worth a pipewire/gst-plugins report, but I don't have an account there to check for an existing issue.