[bug] Linux: blank window — WebKitWebProcess SIGABRT on webkit2gtk 2.52.3; still blank on .2 with WebProcess alive

## Summary

Buzz Desktop opens a window that never renders any UI on Ubuntu 26.04 (Wayland, Intel iGPU). The Rust backend runs fine: identity persists, the media proxy binds, the repos dir resolves, and `buzz-acp` connects to the relay, discovers channels, and reports `presence set to online`. The webview alone fails. Buzz logs nothing about it, so the app appears to start cleanly.

`WebKitWebProcess` aborts itself seconds after exec. I confirmed that with strace and an apport core dump. Downgrading WebKit one revision stops the abort and the window stays blank, so two separate problems exist.

## Environment

| | |
|---|---|
| Buzz | 0.5.14 and 0.5.17 (`.deb` from GitHub releases) |
| OS | Ubuntu 26.04 LTS (resolute), upgraded in place from 22.04 |
| Kernel | 7.0.0-29-generic |
| Session | Wayland, GNOME Shell 50.1 |
| GPU | Intel Alder Lake-P GT2 [Iris Xe] `8086:46a6`, i7-1260P (no NVIDIA) |
| WebKitGTK | `libwebkit2gtk-4.1-0` 2.52.3-0ubuntu0.26.04.3, also tested .2 |
| libsoup3 | 3.6.6-1 |
| GStreamer | 1.28.2-1 |
| GLib | 2.88.0-1 |
| GTK3 | 3.24.52-0ubuntu1 |

## Two failure modes

| WebKitGTK | WebKitWebProcess | UI |
|---|---|---|
| `2.52.3-0ubuntu0.26.04.3` | execs, spawns ~20 threads, then SIGABRT (core dumped) | blank |
| `2.52.3-0ubuntu0.26.04.2` | survives, 50 threads, holds ~12% CPU | blank |

## Evidence

I ran `strace -f -e trace=execve,clone,clone3` on a blank launch. WebKit does launch the web process, so nothing fails at spawn time:

```
execve("/usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess",
[".../WebKitWebProcess", "4", "35"], 0x... /* 100 vars */) = 0
clone3(...) x ~20 threads
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=, si_uid=1000} ---
+++ killed by SIGABRT (core dumped) +++
```

`si_code=SI_TKILL` with `si_pid` matching its own pid means the process called `abort()` on itself.
No external kill, no OOM.

The apport report (`/var/crash/..._WebKitWebProcess.1001.crash`) records:

```
ProblemType: Crash
Signal: 6
ExecutablePath: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess
Package: libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.26.04.3
ProcCmdline: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 4 35
StacktraceTop:
pthread_kill () from /usr/lib/x86_64-linux-gnu/libc.so.6
raise () from /usr/lib/x86_64-linux-gnu/libc.so.6
abort () from /usr/lib/x86_64-linux-gnu/libc.so.6
?? () from /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0
?? () from /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0
```

apport captured no `AssertionMessage`, and no assertion text appears anywhere in the report. That fits a `RELEASE_ASSERT` or `CRASH()` in a release build.

Ubuntu 26.04 gives no way to symbolize this. `libwebkit2gtk-4.1-0-dbgsym` exists on ddebs for `...26.04.2` and returns 404 for `...26.04.3`. The archive holds no newer WebKit either: I probed `.4`, `2.52.4`, `2.52.5` and `2.54.0`, all 404.

A blank launch logs the lines below. A launch that rendered logs the same lines in the same order:

```
buzz-desktop: WebKit rendering left as-is — no NVIDIA GPU and not an AppImage
buzz-mesh: installed tokio runtime with 8 MiB worker stacks
buzz-desktop: team-membership-repair: repaired N record(s)
buzz-desktop: persisted identity pubkey
buzz-desktop: media proxy listening on 127.0.0.1:
buzz-desktop: repos dir resolved at boot — REPOS symlinked to configured
buzz-mesh: status report after startup failed: relay unreachable: could not connect to relay
```

`buzz-acp` connects one second later, so that `relay unreachable` line misleads.

## Leads

**`unsetenv()` runs after thread creation.** With `G_MESSAGES_DEBUG=all`, GLib flags two calls on every launch, both after the tokio runtime starts:

```
buzz-mesh: installed tokio runtime with 8 MiB worker stacks
(buzz-desktop:PID): GLib-DEBUG: unsetenv() is not thread-safe and should not be used after threads are created
(buzz-desktop:PID): GLib-DEBUG: unsetenv() is not thread-safe and should not be used after threads are created
```

`unsetenv()` after threads exist can corrupt `environ`, and WebKit copies `environ` into each auxiliary process it forks (see `/* 100 vars */` above). Launches that rendered show the same warning, so I cannot tie it to the symptom. It stands as a thread-safety bug on its own. I suspect the code that strips reserved env keys, or the code that manages `WEBKIT_DMABUF_RENDERER_FORCE_SHM`.

**`WebKitGPUProcess` never starts.** A full strace contains two WebKit execs, `WebKitNetworkProcess` and `WebKitWebProcess`. On WebKitGTK 2.52 the GPU process composites content, so its absence could explain a live webview that paints nothing.

**The surviving web process holds ~12% CPU** on WebKit `.2` instead of idling. The 0.5.17 entry `fix(desktop): eliminate mounted-view CPU burn` may relate, though 0.5.17 fails as well.

## Ruled out, with evidence

- `WEBKIT_DMABUF_RENDERER_FORCE_SHM=1` causes a blank window on 2.52.3. It helped on an earlier WebKit build, then inverted after an Ubuntu WebKit update. I removed it.
- `--safe-rendering` also gives a blank window. It refuses to start while `FORCE_SHM` is set, so testing the flag requires unsetting the variable first.
- WebKitGTK works on this machine. `/usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser about:blank` spawns its `WebKitWebProcess` and renders on every attempt, same library, same session.
- The WebKit sandbox works. Zero AppArmor denials for buzz, webkit or bwrap, with `kernel.apparmor_restrict_unprivileged_userns=1` set. glycin uses `bwrap` in the same process.
- systemd app-scope limits are not involved: `MemoryMax=infinity`, `MemoryHigh=infinity`, `TasksMax=37305`, no OOM events. Launching detached via `setsid`, outside any app scope, fails the same way.
- No resource pressure: 21 GB of 30 GB available, swap at 0 B, PSI memory pressure `0.00` (3 µs total for the whole boot), zero OOM kills.
- `/dev/shm` sits at 3% of 16 GB. The process holds 62 file descriptors against a 524288 limit.
- libsoup3 is 3.6.6, past the 3.4 floor, so the GitButler #12885 mismatch pattern does not apply.
- One leftover `~ubuntu24.04` GStreamer plugin exists (`gstreamer1.0-icamera`), and `gst-inspect-1.0 icamerasrc` loads it against GStreamer 1.28.2 with exit 0.
- WebKit installed matches candidate. `apt update && apt upgrade` changes nothing.
- The relay answers HTTP 200, and `buzz-acp` connects, subscribes and goes online.
- A second instance launched while another shuts down produces a guaranteed blank window, with a truncated log that stops after the rendering line and the tokio line. I excluded that case by confirming no other process was alive before each run above.

## Reproduction

1. Ubuntu 26.04, Wayland, Intel iGPU, `libwebkit2gtk-4.1-0` 2.52.3-0ubuntu0.26.04.3.
2. Install the Buzz 0.5.17 `.deb` and launch it, from the dock icon or a shell.
3. The window opens and draws its decorations. The content area stays empty.
4. `ps -C WebKitWebProcess` returns nothing, and `/var/crash/` gains a SIGABRT report.

On 0.5.14 the UI rendered on some launches, which pointed at a race. I measured those hit rates using a live `WebKitWebProcess` as a proxy for a rendered UI, and that proxy fails: on WebKit `.2` the process lives while the window stays blank. Discount any frequency I quote. Only visual confirmation counts.

## Questions

- Does Buzz expect `WebKitGPUProcess` to start on WebKitGTK 2.52? Its absence looks significant.
- Can the `unsetenv()` calls move ahead of tokio runtime startup, or use an approach that leaves
`environ` alone?
- Could Buzz log `WebKitWebView::web-process-terminated`? A dead webview currently produces silence,
which cost me two days of bisecting the wrong layers.

I can run more diagnostics. I hold strace traces, 18 labelled launch logs, and a failure that reproduces on every launch of 0.5.17.

Begin with the Ubuntu 26.04 reproduction and the captured strace and apport logs. Trace the launch code around the two unsetenv() calls, WEBKIT_DMABUF_RENDERER_FORCE_SHM handling, and WebKitWebView web-process termination, comparing the result with MiniBrowser. Done means the blank-window failure is explained or fixed and web-process termination is logged.

Written by the indexing model from the issue text.