[Bug] Invisible/transparent window on AMD RDNA4: WebKitGTK Skia GPU path fails on non-conformant radv; WEBKIT_SKIA_ENABLE_CPU_RENDERING=1 fixes it

## Describe the bug

On AMD RDNA4 GPUs (Mesa `radv` still marks gfx1200 non-conformant), the Buzz Desktop window is **invisible/transparent**: the window opens, but the webview never paints (or paints one frame and then permanently stops repainting after any move/minimize). Because the Tauri window is configured with `"transparent": true` (`desktop/src-tauri/tauri.conf.json`), the failure presents as a ghost window — desktop wallpaper visible through a Buzz-shaped frame, titlebar rendered normally.

The root cause is **not** the dmabuf renderer issue from #2338 (that workaround does not help here). WebKitGTK 2.52 renders via **Skia**, and on this GPU Skia's GPU path goes through Vulkan/`radv`, which self-reports:

```
WARNING: radv is not a conformant Vulkan implementation, testing use only.
```

Forcing Skia to CPU rasterization fully fixes rendering:

```bash
WEBKIT_SKIA_ENABLE_CPU_RENDERING=1
```

## To Reproduce

1. Machine with an AMD RDNA4 GPU (tested: RX 9060 XT / gfx1200), Mesa 26.1.2, KDE Plasma 6.6.5 (Wayland session)
2. Launch Buzz Desktop (either the 0.4.23 AppImage after the #2335 libsystemd fix, **or** a from-source `just dev` build using system webkit2gtk-4.1 2.52.4 — both reproduce)
3. Window opens; content area is transparent (or paints the page background once, then goes permanently transparent after moving/minimizing the window)
4. Relaunch with `WEBKIT_SKIA_ENABLE_CPU_RENDERING=1` → full UI renders correctly and survives move/minimize

## Expected behavior

The window should render its content, or fall back to a rendering path that works instead of an invisible window.

## Supporting Material

Isolation matrix (all on the same machine/session):

| Configuration | Result |
|---|---|
| Default (XWayland, `GDK_BACKEND=x11` from AppRun hook) | transparent |
| `WEBKIT_DISABLE_DMABUF_RENDERER=1` (the #2338 workaround) | WebKitWebProcess stays alive, still transparent |
| `GDK_BACKEND=wayland` (native Wayland; no `eglMakeCurrent` failure on AMD, unlike tauri#8541 on Intel) | transparent |
| `LIBGL_ALWAYS_SOFTWARE=1` | transparent (expected in hindsight — Skia uses Vulkan here, not GL) |
| **`WEBKIT_SKIA_ENABLE_CPU_RENDERING=1`** | **renders correctly** |

Notes:
- Reproduces identically with the **bundled** WebKitGTK (0.4.23 AppImage) and the **system** WebKitGTK 2.52.4 (from-source `just dev`), on both X11 and native Wayland — so it is not an AppImage packaging problem; it is the Skia GPU path on this GPU generation.
- `WebKitWebProcess` and `WebKitNetworkProcess` run normally throughout; frontend JS executes (Vite client console messages come through in dev). Only painting is broken.
- Distinct failure mode from #2338 (Intel: core dump, fixed by disabling dmabuf; RDNA4: silent no-paint, dmabuf var irrelevant).

## Environment

- OS: CachyOS (Arch-based), KDE Plasma 6.6.5, Wayland session (rootless XWayland)
- GPU: AMD Radeon RX 9060 XT (RDNA4 / gfx1200), Mesa 26.1.2-arch2.1 (radv)
- WebKitGTK: bundled (0.4.23 AppImage) and system 2.52.4-1 — both affected
- Buzz: 0.4.23 AppImage **and** from-source at current main — both affected

## Additional context

Suggested mitigations, in increasing order of effort:

1. Document `WEBKIT_SKIA_ENABLE_CPU_RENDERING=1` as a known workaround for AMD GPUs that radv flags non-conformant (currently RDNA4).
2. Set it conditionally in the AppRun hook when radv reports a non-conformant device (or expose a `--safe-rendering` launch flag).
3. Reconsider unconditional `"transparent": true` on the main window — when the webview fails to paint for *any* reason, transparency turns a diagnosable "blank window" into a confusing invisible app. An opaque fallback background would make every rendering bug in this class far more user-debuggable.

Happy to test patches on this hardware.

Related: #2338 (different root cause, same symptom neighborhood), #2335 (libsystemd fix needed first to even launch the AppImage on Arch).

Start with desktop/src-tauri/tauri.conf.json and the AppRun hook mentioned in the report, then reproduce the issue on the stated AMD RDNA4 environment using the isolation matrix. Done means the desktop content renders reliably without requiring a manual workaround, or the chosen mitigation is documented and verified on the affected configurations.

Written by the indexing model from the issue text.