feat(linux): zero-copy 4:4:4 — the EGL worker converts to planar YUV444 on the GPU

A 4:4:4 session no longer falls to the CPU path (SHM capture + swscale
RGB→YUV444P + re-upload — the fps-ceiling triple tax). The zero-copy worker
grows a Yuv444Blit: three full-res R8 GL passes (the proven BT.709
coefficients; studio or full range per PUNKTFUNK_444_FULLRANGE, read by both
processes so pixels and VUI flip together) into ONE stacked 3-plane pitched
CUDA allocation — which keeps the worker↔host wire and IPC single-plane. The
encoder copies the planes into ffmpeg's yuv444p CUDA surface and hevc_nvenc
emits Range-Extensions 4:4:4 natively.

ImportKind::Tiled444 is APPENDED to the worker protocol (a worker outliving a
replaced host binary must keep the old tags stable; an old worker just errors
the import, which the fail machinery already handles). A 4:4:4 session on a
LINEAR/gamescope capture — no convert wired there — fails with a clear message
instead of letting hevc_nvenc silently subsample. caps().chroma_444 now keys
off the session (it missed the GPU path when keyed off the swscale's
existence).

Live-verified on the CachyOS VM (RTX 5070 Ti): per-frame "imported to CUDA
yuv444=true", stream Rext/yuv444p/bt709 in both tv and pc range, no CPU-path
warning.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

crates/punktfunk-host/src/encode/sw.rs

@@ -184,9 +184,9 @@ impl Encoder for OpenH264Encoder {
             }
             // NV12/P010 are GPU-resident video-processor outputs for the NVENC path; the software
             // encoder never receives them (it only gets CPU RGB frames).
-            PixelFormat::Nv12 | PixelFormat::P010 => {
+            PixelFormat::Nv12 | PixelFormat::P010 | PixelFormat::Yuv444 => {
                 anyhow::bail!(
-                    "software encoder cannot encode YUV GPU textures (NV12/P010 → NVENC only)"
+                    "software encoder cannot encode YUV GPU frames (NV12/P010/YUV444 → NVENC only)"
                 )
             }
         };