fix(pf-encode/windows): cover the Linux HDR pixel formats in the win swscale match

The GNOME 50 HDR work added PixelFormat::X2Rgb10 / X2Bgr10 but only taught the
Linux encoders about them. `sws_src` in the Windows-gated ffmpeg_win.rs matches
PixelFormat exhaustively, so the Windows host stopped compiling:

    error[E0004]: non-exhaustive patterns: `X2Rgb10` and `X2Bgr10` not covered
      --> crates\pf-encode\src\enc\windows\ffmpeg_win.rs:132:14

Linux CI never caught it — the file is cfg(windows), so `cargo clippy
--workspace` on the Linux runner never compiles it.

Both are Linux-only screencast formats (the Windows HDR path stays
Rgb10a2/P010, per the PixelFormat docs), so they join the existing bail arm.
Spelled out rather than folded into a `_` catch-all so the next PixelFormat
addition breaks this match again on purpose.

Verified: cargo check --workspace --all-targets --features nvenc,amf-qsv on the
Windows box (192.168.1.173).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

crates/pf-encode/src/enc/windows/ffmpeg_win.rs

@@ -136,7 +136,15 @@ fn sws_src(format: PixelFormat) -> Result<Pixel> {
         PixelFormat::Rgba => Pixel::RGBA,
         PixelFormat::Rgb => Pixel::RGB24,
         PixelFormat::Bgr => Pixel::BGR24,
-        PixelFormat::Nv12 | PixelFormat::P010 | PixelFormat::Rgb10a2 | PixelFormat::Yuv444 => {
+        // X2Rgb10/X2Bgr10 are the Linux GNOME 50 HDR screencast formats — the Windows HDR path
+        // stays Rgb10a2/P010, so they can't reach this capture-side conversion. Listed explicitly
+        // (not via `_`) so the next PixelFormat addition breaks this match again on purpose.
+        PixelFormat::Nv12
+        | PixelFormat::P010
+        | PixelFormat::Rgb10a2
+        | PixelFormat::Yuv444
+        | PixelFormat::X2Rgb10
+        | PixelFormat::X2Bgr10 => {
             bail!("ffmpeg_win swscale path supports packed RGB/BGR only; got {format:?}")
         }
     })