[Bug][Linux] Window freezes: WebKitWebProcess dies with SIGILL (AVX vmovaps in JavaScriptCore) on CPUs without AVX

**Describe the bug**

On Linux, the Buzz window freezes and stops responding to input a few seconds to a couple of minutes after launch. The window stays on screen and `buzz-desktop` keeps running, so it looks like a hang — but the WebKitGTK renderer has actually died.

Root cause is a `SIGILL` in JavaScriptCore: the crashing instruction is a VEX-encoded (AVX) `vmovaps`, and this CPU has no AVX. Intel disables AVX on Pentium Gold / Celeron parts, so any such machine hits this.

```
kernel: traps: WebKitWebProces[255352] trap invalid opcode
ip:72354964e52c in libjavascriptcoregtk-4.1.so.0.10.11[24e52c,723549566000+1856000]
buzz-desktop[255315]: [pageProxyID=6, webPageID=7, PID=255352] WebPageProxy::dispatchProcessDidTerminate: reason=Crash
WebKitNetworkProcess[255332]: [webProcessIdentifier=4] NetworkConnectionToWebProcess::didClose: WebProcess closed its connection.
```

Disassembling that offset in the distro library:

```
$ objdump -d --start-address=0x24e500 --stop-address=0x24e540 \
/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.1.so.0.10.11
24e52c: c5 f8 29 84 24 b0 00 00 00 vmovaps %xmm0,0xb0(%rsp)
```

The site sits immediately before `JSC::MacroAssemblerX86_64::collectCPUFeatures()` — a JIT support/probe trampoline that saves GPRs and then the xmm registers with an AVX move that is not gated behind a CPU-feature check.

CPU flags on the affected machine (no `avx`):

```
model name : Intel(R) Pentium(R) Gold G6400 CPU @ 4.00GHz
flags : ... sse4_2 xsave xsaveopt xsavec xsaves ...
```

**Steps to reproduce**
1. On an x86-64 CPU without AVX (e.g. Intel Pentium Gold G6400), install the Buzz `.deb`.
2. Launch `buzz-desktop`.
3. Within roughly 30 seconds the window stops repainting and no longer reacts to clicks or keyboard.
4. `pgrep -af WebKitWebProcess` shows no renderer, while `buzz-desktop` is still alive.
5. `journalctl --since '-5min' | grep -E 'invalid opcode|dispatchProcessDidTerminate'` shows the trace above.

Reproduced on every launch (3/3), including a crash recorded by apport before any debugging (`/var/crash/_usr_lib_x86_64-linux-gnu_webkit2gtk-4.1_WebKitWebProcess.1000.crash`, `SignalName: SIGILL`, `Signal: 4`).

**Expected behavior**

The app stays usable on CPUs without AVX. At minimum, a dead renderer should be detected and reported to the user (or the web view reloaded) instead of leaving a frozen window with no indication of what happened.

**Version and platform**

- Buzz version: 0.5.2 (`.deb`, `dpkg -l buzz` → 0.5.2 amd64)
- OS: Ubuntu 24.04, kernel 7.0.0-28-generic, Wayland session
- WebKit: `libwebkit2gtk-4.1-0` 2.52.3-0ubuntu0.24.04.1
- CPU: Intel Pentium Gold G6400 (Comet Lake, no AVX)

**Logs / additional context**

Workaround that fixes it completely — force the JavaScriptCore interpreter:

```
JSC_useJIT=0 buzz-desktop
```

With `JSC_useJIT=0` the renderer stays alive and the UI remains responsive indefinitely (verified over several minutes of normal use); without it the renderer dies within ~30 s. Made permanent via a `~/.local/share/applications/Buzz.desktop` override with `Exec=env JSC_useJIT=0 buzz-desktop %u`.

Two suggestions for Buzz itself, independent of the upstream WebKit bug:

1. Handle renderer termination — Tauri exposes the `WebPageProxy` terminate as a webview crash; showing an error or reloading beats a silently frozen window.
2. Consider setting `JSC_useJIT=0` (or gating on `/proc/cpuinfo` lacking `avx`) in the Linux launcher until webkit2gtk ships a fix, since on affected CPUs the app is 100% unusable otherwise.

Also worth noting: the systemd `.desktop` entry declares `MimeType=x-scheme-handler/buzz` but its `Exec=buzz-desktop` has no `%u`, so `buzz://` URLs are not passed to the app.

Likely also the underlying cause of the class of reports where the Linux window "just freezes"; distinct from #2982, which is a Skia/COLRv1 font-rendering abort.