fix(host): IDD capture immune to display-config stalls/flaps + metronomic-recovery self-diagnosis

Field report (0.8.2→0.8.4): metronomic stutter every ~3.7-4 s, each event a
double-jolt, on ALL clients — and the same box stuttered on Apollo (virtual
display) but not Sunshine (physical). The disturbance class is host-side
display-topology events / display-poller software (SteelSeries-GG class,
Apollo #480/#358/#368) hitting the virtual-display path. Three changes make
the IDD path resilient to it and self-diagnosing:

- DescriptorPoller: the display-descriptor CCD queries (QueryDisplayConfig
  twice per sample) serialize on the session-global display-config lock,
  which topology churn and display-poller software can hold for tens-to-
  hundreds of ms. Polled inline, that stall landed ON the capture/encode
  thread 4x/s — a periodic frame hitch, invisible in any log. A dedicated
  thread now samples every 250 ms and publishes a snapshot; the capture loop
  pays one uncontended mutex read, and a sample slower than 50 ms logs a
  rate-limited warn — the stall is measured instead of streamed.

- Flap immunity: advanced_color_enabled returns Option (None on a failed
  query or the target briefly missing from the active paths during a
  re-probe) and the poller keeps last-known-good per field — a transient no
  longer reads as "HDR off", which used to cost an HDR session TWO spurious
  ring recreates (false, then true again a poll later). On top, a two-strikes
  debounce: only two consecutive samples agreeing on the same new descriptor
  trigger the recreate; a real "Use HDR" flip or game mode-set still lands
  in ~1/2 s.

- RecoveryCadence: served recovery IDRs within 1.5 s coalesce into one event
  (a double-jolt's paired IDRs count once); four consecutive events evenly
  spaced (±20%) warn "client keyframe recoveries are METRONOMIC — a periodic
  host/display disturbance, not random network loss" with the measured
  period (re-warn ≤ every 30 s) — so an affected host self-diagnoses in its
  own log / web console instead of reporting "nothing in the logs". Unit
  tests include the field report's exact double-jolt-pair schedule.

Verified: host tests + clippy clean on Linux and on the RTX box (211/211,
--features nvenc).

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

crates/punktfunk-host/src/windows/win_display.rs

@@ -169,12 +169,15 @@ pub(crate) unsafe fn set_advanced_color(target_id: u32, enable: bool) -> bool {
 /// actually ON for the virtual display right now (e.g. because the user toggled it in Windows display
 /// settings). The capture/encode pipeline follows the monitor's real colorspace (WGC → FP16 → NVENC
 /// Main10 BT.2020 PQ), so this is the authoritative "is this an HDR session" signal — NOT the
-/// handshake-negotiated bit depth. Returns false if the target isn't found / the query fails.
-pub(crate) unsafe fn advanced_color_enabled(target_id: u32) -> bool {
+/// handshake-negotiated bit depth. `None` when the query fails or the target isn't in the active-path
+/// list (both happen transiently during a display-topology re-probe): the caller decides the fallback —
+/// the capture loop's poller keeps the last known value, since reading a blip as "HDR off" used to cost
+/// an HDR session TWO spurious ring recreates (false, then true again a poll later).
+pub(crate) unsafe fn advanced_color_enabled(target_id: u32) -> Option<bool> {
     let mut np = 0u32;
     let mut nm = 0u32;
     if GetDisplayConfigBufferSizes(QDC_ONLY_ACTIVE_PATHS, &mut np, &mut nm).is_err() {
-        return false;
+        return None;
     }
     let mut paths = vec![DISPLAYCONFIG_PATH_INFO::default(); np as usize];
     let mut modes = vec![DISPLAYCONFIG_MODE_INFO::default(); nm as usize];
@@ -188,7 +191,7 @@ pub(crate) unsafe fn advanced_color_enabled(target_id: u32) -> bool {
     )
     .is_err()
     {
-        return false;
+        return None;
     }
     for p in paths.iter().take(np as usize) {
         if p.targetInfo.id == target_id {
@@ -199,12 +202,12 @@ pub(crate) unsafe fn advanced_color_enabled(target_id: u32) -> bool {
             info.header.id = p.targetInfo.id;
             if DisplayConfigGetDeviceInfo(&mut info.header) == 0 {
                 // value bit 1 = advancedColorEnabled (bit 0 = advancedColorSupported).
-                return (info.Anonymous.value & 0x2) != 0;
+                return Some((info.Anonymous.value & 0x2) != 0);
             }
-            return false;
+            return None;
         }
     }
-    false
+    None
 }
 
 /// Force the freshly-added SudoVDA monitor to the client's exact `WxH@Hz`. The ADD IOCTL only