feat(hdr): GNOME 50 HDR screencast capture + Linux Main10 encode

GNOME 50 (Mutter MR 4928, PipeWire >= 1.6) added HDR screen sharing for
monitor streams: 10-bit PQ formats (xRGB_210LE/xBGR_210LE) with MANDATORY
BT.2020 + SMPTE-2084 colorimetry props, advertised while the mirrored
monitor is in BT.2100 colour mode. Wire the Linux host into it end-to-end
on the GameStream desktop-mirror path (PUNKTFUNK_VIDEO_SOURCE=portal):

* pf-frame: PixelFormat::X2Rgb10/X2Bgr10 (DRM XR30/XB30; X2Bgr10 is the
  Windows Rgb10a2 layout) + fourccs.
* pf-capture: want_hdr portal offer — HDR-only LINEAR-dmabuf pods with
  MANDATORY PQ/BT.2020 props (SHM excluded: Mutter's SHM record path
  paints 8-bit ARGB32 regardless of format; tiled excluded: the EGL
  de-tile blit is 8-bit RGBA8), negotiated-colorimetry parse, generic
  HDR10 hdr_meta(), packed-10-bit CPU cursor blend, a process-wide SDR
  downgrade latch on negotiation timeout, and a DisplayConfig BT.2100
  colour-mode probe (gnome_hdr_monitor_active).
* pf-encode: libav NVENC X2RGB10->P010 swscale (BT.2020 limited) ->
  HEVC Main10 / 10-bit AV1 with PQ VUI; VAAPI 10-bit on both paths (CPU
  P010 upload + dmabuf XR30 scale_vaapi p010/bt2020); can_encode_10bit
  now probes for real on Linux; 10-bit sessions route around the
  8-bit-only Vulkan-video/direct-NVENC backends.
* GameStream: host_hdr_capable() Linux arm, live monitor-HDR check at
  RTSP honor time, capturer-pool reuse keyed on HDR-ness, gs_bit_depth
  covers the new formats. New `punktfunk-host hdr-probe` diagnostic and
  a PUNKTFUNK_SPIKE_HDR spike lever.
* Native plane stays honestly 8-bit via capturer_supports_hdr(): Mutter
  RecordVirtual streams are SDR-only upstream (GNOME 50 and 51-dev), so
  virtual-display sources cannot deliver HDR yet.

Validated on the RTX 5070 Ti (GNOME 50.3 / PipeWire 1.6.8): the Main10
probes pass and the ignored nvenc_hdr10_smoke GPU test emits an IDR that
ffprobe reads as Main 10 / yuv420p10le / bt2020nc / smpte2084 / limited.
Live HDR capture negotiation still needs an HDR monitor on glass; VAAPI
10-bit needs the AMD box.

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

crates/punktfunk-host/src/native/handshake.rs

@@ -212,10 +212,22 @@ pub(super) async fn negotiate(
     // label that matches the stream.
     let host_wants_10bit = pf_host_config::config().ten_bit;
     let client_supports_10bit = hello.video_caps & punktfunk_core::quic::VIDEO_CAP_10BIT != 0;
+    // The capture side must be able to deliver a 10-bit HDR source for the NATIVE plane's
+    // virtual-output capture — the honest-downgrade gate, mirroring `capturer_supports_444`.
+    // Windows IDD-push can (it proactively enables advanced colour); Linux cannot: Mutter's
+    // RecordVirtual virtual-monitor streams are 8-bit-only upstream (GNOME 50 added HDR for
+    // *monitor* streams only — the GameStream portal-mirror path uses that; see
+    // `gamestream::host_hdr_capable`), so a Linux native session honestly stays 8-bit SDR even
+    // though `can_encode_10bit` now probes true on a Main10-capable GPU.
+    let capture_supports_hdr = crate::capture::capturer_supports_hdr();
     // The GPU probe may open a tiny encoder on first use, so run it off the reactor like the
     // 4:4:4 probe below (blocking probes → spawn_blocking), short-circuited behind the cheap
     // gates. The result is cached process-wide per (GPU, codec).
-    let gpu_can_10bit = if host_wants_10bit && client_supports_10bit && codec.supports_10bit() {
+    let gpu_can_10bit = if host_wants_10bit
+        && client_supports_10bit
+        && codec.supports_10bit()
+        && capture_supports_hdr
+    {
         tokio::task::spawn_blocking(move || crate::encode::can_encode_10bit(codec))
             .await
             .context("10-bit capability probe task")?
@@ -227,6 +239,7 @@ pub(super) async fn negotiate(
         bit_depth,
         host_wants_10bit,
         client_supports_10bit,
+        capture_supports_hdr,
         codec = ?codec,
         gpu_can_10bit,
         client_video_caps = hello.video_caps,