[Bug][Linux/Desktop] Renderer (WebKitWebProcess) crashes surface as silent dead window: install a web-process-terminated handler to log + recover

## Summary

When the `WebKitWebProcess` (the WebKitGTK renderer) dies, the Buzz window goes dead but **looks like a freeze**: the main `buzz-desktop` process and `WebKitNetworkProcess` stay alive with no renderer to draw, so the user sees a hung window with no crash dialog, no log line, and no recovery path.

WebKitGTK exposes a `web-process-terminated` signal on `WebKitWebView` precisely for this. Buzz currently installs **no** handler for it (verified: zero references to `web_process_terminated` / `web-process-terminated` / `WebProcessTerminationReason` anywhere in `desktop/src-tauri`).

## Evidence

Surfaced by the thorough diagnosis in #4358 (WebKitWebProcess segfault inside PipeWire's `libpipewire-module-metadata.so`). That crash has an upstream root cause, but it exposed a separable, Buzz-owned gap: **any** renderer crash — from PipeWire, an OOM, a WebKit bug, or anything else — currently presents as an unrecoverable silent freeze rather than a detectable, loggable, recoverable event.

## Location

The seam already exists. `desktop/src-tauri/src/linux_media.rs:63` (`enable_media_capture`) reaches the underlying `webkit2gtk::WebView` via `webview.with_webview(|platform_webview| platform_webview.inner())` and already installs a `connect_permission_request` handler in that same closure. It is wired from `desktop/src-tauri/src/lib.rs` in `on_webview_ready` (the `webview.label() == "main"` branch) and is Linux-gated with a no-op stub on macOS/Windows (`linux_media.rs:108`).

Handling `web-process-terminated` is a sibling hook in the same place — same `WebView`, same closure shape, same platform gating.

## API surface (verified)

`webkit2gtk 2.0.2` (pinned in `desktop/src-tauri/Cargo.toml:46` with the `v2_22` feature) provides, on `WebViewExt`:

```rust
fn connect_web_process_terminated(
&self, f: F) -> SignalHandlerId
```

`WebProcessTerminationReason` distinguishes `Crashed` / `ExceededMemoryLimit` / `TerminatedByApi`, so the handler can log *why* the renderer died — useful signal for exactly the class of bug #4358 reports.

## Proposed fix

In `linux_media.rs` (a sibling `install_web_process_terminated_handler` called from the same `on_webview_ready` site in `lib.rs`), attach a `connect_web_process_terminated` handler that at minimum:

1. **Logs** the termination reason (so a silent freeze becomes a diagnosable log line).
2. **Recovers the renderer** instead of leaving the window dead.

For step 2 there's one design decision worth a maintainer's call:

- **Option A (auto-reload):** immediately reload the webview on termination. Minimum code, restores the UI with no user action. Risk: a renderer that crashes deterministically on load (e.g. #4358's startup-enumeration crash) would crash-loop unless capped — so auto-reload should be rate-limited (at most N reloads within a time window, then fall through to Option B's manual state).
- **Option B (surface a restart affordance):** show a "renderer crashed — click to restart" state in the webview instead of a frozen window, and reload only on user action. No crash-loop risk, slightly worse UX for a one-off transient crash.

Suggested default: **Option B**, or Option A with a small retry cap + backoff that falls through to B. Reload target is reachable via `get_webview_window("main")`, consistent with existing window accessors in `lib.rs`.

Either way, the detect-and-log half is non-controversial and independently shippable.

## Scope note

This issue is deliberately narrow: handle `web-process-terminated` so a renderer crash is logged and recoverable. It is **not** about fixing the #4358 PipeWire segfault itself, which is upstream in PipeWire's client modules and should be pursued against PipeWire. It pairs with #4358 as an example, but the fix benefits every possible renderer-crash cause.