fix(player): stabilize NVIDIA Wayland WebKit startup

[LuorixDev]

Summary

• Add a Linux-only Xephyr + Openbox compatibility backend for NVIDIA Wayland WebKitGTK failures.
• On the first qualifying launch, show an explanation and let the user choose before persisting a backend preference.
• Store the choice in ~/.config/net.stevexmh.amllplayer/linux-webview.json (or $XDG_CONFIG_HOME/net.stevexmh.amllplayer/linux-webview.json); AMLL_LINUX_WEBVIEW_BACKEND remains an explicit override.
• Default Xephyr to 60 Hz, with AMLL_XEPHYR_FPS for explicit high-refresh testing.
• Forward wrapper move, resize, minimize, maximize, and fullscreen actions to the host window manager.
• Fix the closed media-controls channel busy loop and Vite development white screen.

Why

Native WebKitGTK can terminate with a Wayland protocol error or lose rendered content on NVIDIA Wayland. The nested X11 path avoids that failure, but it has different window-management behavior and must not be silently selected for every Linux installation.

The first-run confirmation is displayed in a temporary compatibility session because the native WebView may fail before it can render a prompt. Choosing openbox keeps the compatibility backend; choosing system restarts into the original environment.

User impact

The wrapper code and dependencies compile only on Linux. Non-Linux platforms retain the original window and WebView path. Linux users can edit the saved backend value to openbox, system, x11, wayland, wayland-software, or auto.

Validation

• cargo test -p amll-player --lib linux_webview::tests (12 passed)
• cargo build -p amll-player
• pnpm --filter player build
• git diff --check
• Verified NVIDIA EGL/render-node use in the nested WebKit process.
• Verified first-run configuration is not written until the user chooses a backend.

Known limitation

Xephyr adds a CPU copy/compositing stage because it does not expose DRI3 to nested clients. WebKitGTK can still use the GPU, but this is not equivalent to native Wayland performance.