Title: Hardware video decode fails to render on external monitor wired to the NVIDIA GPU (hybrid Intel+NVIDIA, Omarchy 4.0.0.alpha "Quattro")

## Summary

On a hybrid Intel+NVIDIA laptop with an external monitor connected via HDMI to a port
wired directly to the NVIDIA GPU (not the Intel iGPU), any browser tab playing video
with hardware-accelerated decode renders as **fully transparent** (the desktop
wallpaper shows through where the window should be) for as long as the video plays.
Static page content in the same browser, on the same monitor, renders correctly.

This looks related to #4901 (hybrid Intel+NVIDIA Chromium black screen/corruption) and
PR #5312, but I don't think it's the same root cause, so I'm opening a separate issue
rather than commenting on that thread — details below.

## Environment

- Omarchy version: 4.0.0.alpha ("Quattro" branch, commit `56fbaf46`)
- GPU: Intel Raptor Lake-P (iGPU) + NVIDIA GeForce RTX 5050 Laptop GPU (GB207M, Blackwell, driver 610.57.04)
- Compositor: Hyprland + Aquamarine
- External display: Samsung U28E590, connected via HDMI
- Browser: Brave 151.1.93.138 (Chromium-based); reproduced independently with stock Chromium 151.0.7922.173

## Why this looks different from #4901

- #4901's signature is `eglCreateImage failed with 0x00003009` (`EGL_BAD_MATCH`) coming
  from the browser's own GPU process, attributed to GLVND resolving
  `10_nvidia.json` before `50_mesa.json` for the browser's internal EGL context.
- On this machine, the browser's GPU process is confirmed to already be using the
  correct Mesa/Intel EGL implementation: `--render-node-override=/dev/dri/renderD129`
  (Intel) is present on the GPU process command line, and `chrome://gpu` shows GPU1
  (Intel/Mesa, driver 26.2.1) as `*ACTIVE*`, with Compositing, WebGL and Video Decode
  all reporting "Hardware accelerated" and zero GPU process crashes.
- The failure isn't a crash or corruption — it's the compositor never drawing the
  surface at all (wallpaper shows through, not black, not garbled), and only while a
  video is actively decoding.
- Hyprland's log shows this monitor is scanned out through a distinct DRM backend:
  `drm: Starting backend for /dev/dri/card1, with driver nvidia-drm with primary /dev/dri/card2`
  — i.e. Aquamarine composites on the Intel GPU (card2) but this particular output's
  DRM device is the NVIDIA GPU (card1), which requires a cross-GPU buffer import to
  scan out the composited frame.

My working theory: the hardware-decoded video plane (VAAPI on Intel, likely with a
DRM format modifier Mesa uses for video surfaces) fails to import into the NVIDIA
GPU's scanout path, while ordinary ARGB UI buffers import fine — hence static content
works and only the video surface goes missing. `render:direct_scanout` is disabled in
this config, so it isn't a direct-scanout bypass issue.

## Reproduction

1. Hybrid Intel+NVIDIA laptop, external monitor on an HDMI port wired to the NVIDIA GPU
   (confirm via Hyprland log: look for `drm: Starting backend for /dev/dri/cardN, with
   driver nvidia-drm`).
2. Open any browser tab with hardware-accelerated video (e.g. a YouTube video) on that
   external monitor.
3. The video region (in this case, the whole tab) renders as transparent for the
   duration of playback. Moving the window to the internal panel (Intel-attached)
   is expected to fix it, though I haven't confirmed that side of the comparison yet.

## What I haven't confirmed yet

- Whether moving the window to the Intel-attached internal panel actually fixes it
  (would confirm the cross-GPU scanout theory more directly).
- Whether disabling hardware video decode (`--disable-accelerated-video-decode`)
  avoids the issue, which would point to a viable browser-side mitigation.
- Whether this is an Aquamarine/Hyprland bug (cross-GPU import for scanout) rather
  than anything Omarchy-specific — if so the fix may belong upstream rather than here.

Happy to gather more diagnostics if useful.