docs(windows-rewrite): secure desktop validated on glass — mark M3 done, retire the biggest risk

Owner-confirmed on glass (2026-06-25, "works great"): the IDD-push primary path
captures the lock/UAC secure desktop AND input reaches the streamed console
session. This was the single biggest open risk — the whole capture strategy
(Decision B: IDD-push primary for everything incl. secure desktop, WGC/DDA
demoted) rested on it. Now proven, not asserted.

- §15: M3 row → DONE (secure desktop); removed the secure-desktop gate from
  "What genuinely remains" (renumbered); added it to "Resolved since §11".
- §11 "IDD-push input + secure desktop" open item → RESOLVED.
- §14 critique "SINGLE BIGGEST RISK: the secure-desktop claim" → RESOLVED.

The WGC-relay / secure-DDA path is no longer load-bearing — kept only as a
non-IddCx-hardware fallback. Remaining rewrite work is migration/cleanup (M4
gamepad drivers, M5/M6, slot-reclaim), none blocking the validated path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/windows-host-rewrite.md

@@ -586,10 +586,10 @@ What remains are **technical unknowns to confirm on the RTX box** (not user deci
 - **Driver swap-chain reuse.** Does the clean ownership model (`EvtCleanupCallback` + DeviceContext state
   + single `Monitor` identity) actually fix the "reused swap-chain dies after ~2 sessions" root cause? If
   not, the residual serialization stays inside `VirtualDisplayManager`.
-- **IDD-push input + secure desktop.** Confirm `serve` runs in the console session so `SendInput` reaches
+- **IDD-push input + secure desktop. ✅ RESOLVED (owner-confirmed on glass, 2026-06-25).** `serve` runs in
-  the streamed desktop (a code comment warns about Session 0→1); confirm IDD-push frames flow through the
+  the console session so `SendInput` reaches the streamed desktop, and IDD-push frames flow through the lock
-  lock screen / UAC (owner reports yes — verify and lock it in as the primary, demoting the DDA secure
+  screen / UAC — both confirmed live ("works great"). Locked in as the primary; the DDA secure leg is
-  leg to fallback).
+  demoted to a non-IddCx fallback. (See [§15](#15-current-status-2026-06-25).)
 - **Does the demoted DDA fallback still need the `win32u` hook** against pf-vdisplay, or was that purely
   a SudoVDA/hybrid pathology? If unneeded, the self-modifying-code hook can be deleted entirely.
 - **AMF/QSV** stays CI-only (no hardware) — system-readback default, zero-copy experimental.
@@ -775,10 +775,11 @@ the locally-duplicated header/MAGIC/name consts.
 ### Critique verdict + the big risk
 Plan is implementation-ready once the 4 CI-checkable unknowns are gates (3 now resolved by the surface-assert
 + `.Size` machinery presence; std-under-UMDF is the STEP-0 gate). **SINGLE BIGGEST RISK: the secure-desktop
-claim** — the plan retires the proven two-process WGC relay + DDA on the *unproven* assertion that one
+claim** — ~~the plan retires the proven two-process WGC relay + DDA on the *unproven* assertion that one
-IddPushCapturer captures the lock/UAC secure desktop directly (IDD-push is opt-in today behind
+IddPushCapturer captures the lock/UAC secure desktop directly~~ → **✅ RESOLVED (owner-confirmed on glass,
-`PUNKTFUNK_IDD_PUSH`). Make it a blocking on-glass gate (step 6) and keep the WGC relay recoverable for one
+2026-06-25): the IddPushCapturer captures the lock/UAC secure desktop AND input reaches it — "works
-release. Other defined-failure-branch items: monitor `EvtCleanupCallback` firing, IDD_PERSIST/Reconfigure,
+great."** The assertion held; this risk is retired (see [§15](#15-current-status-2026-06-25)). The WGC relay
+stays only as a non-IddCx-hardware fallback. Other defined-failure-branch items: monitor `EvtCleanupCallback` firing, IDD_PERSIST/Reconfigure,
 concurrent-monitor device sharing, host↔driver `protocol_version` lockstep.
 
 ---
@@ -805,27 +806,32 @@ that branch's commits, not the M2 greenfield tree the build order imagined.
 | **§2.5** — ownership-model rewrite (`VirtualDisplayManager`/`MonitorLease`); swap-chain-reuse / monitor-leak | ✅ **DONE / RESOLVED** | `windows-host-goal1` §2.5 (`1520201`…`683c81b`); reconnect-leak A/B: 0 leaked monitors |
 | **Goal-1 host refactor** (the in-place §2.2–2.5 realization, incl. `EncoderCaps`) | ✅ **DONE** | `windows-host-goal1` branch — all 6 stages + §2.5 + 3 seam tightenings |
 | **Game-capture bug (GB1)** — fullscreen game breaks IDD-push | ✅ **FIXED** | `c87bfe0`/`f98ab07`/`789ad49`; see [game-capture-bug.md](windows-host-rewrite-game-capture-bug.md) |
-| **M3** — service / input / audio cleanup | 🟡 code present (largely via the existing host + goal1) | — |
+| **M3** — service / input / audio / **secure desktop** | ✅ **DONE** — secure desktop (lock/UAC) on-glass validated | owner-confirmed 2026-06-25: IDD-push captures the secure desktop + input reaches it |
 | **M4** — gamepad drivers (`pf_dualsense`/`pf_xusb`) onto the unified stack, WDF device contexts (true multi-pad) | ❌ **NOT STARTED** | old gamepad-driver crates still separate |
 | **M5** — demoted WGC/DDA fallback port + GameStream-on-`session/pipeline` + AMF/QSV (no hw) | 🟡 **PARTIAL** | fallbacks exist; not re-shaped onto the new seams |
 | **M6** — cut over + delete the old monoliths | 🟡 **PARTIAL** | old `vdisplay-driver/` tree deleted (`a2bd0cd`); host monoliths remain |
 
 ### What genuinely remains
 
-1. **Secure-desktop on-glass gate (the single biggest open risk, §14 STEP 6 critique).** IDD-push capturing
+With the secure-desktop gate passed (below), the primary-path risk is retired. What's left is migration /
-   the lock screen / UAC with `serve` in the console session is **asserted, not yet locked on glass**. Until
+cleanup / a driver robustness gap — none of it blocking the validated streaming path:
-   it passes, keep the WGC-relay / secure-DDA path recoverable. Hardware-gated (RTX box; ephemeral).
+
-2. **M4 — gamepad-driver migration** onto `windows-drivers-rs` (WDF device contexts → true multi-pad). The
+1. **M4 — gamepad-driver migration** onto `windows-drivers-rs` (WDF device contexts → true multi-pad). The
    proven recipe exists; ~2–3 days, hardware-gated.
-3. **M5/M6 cleanup** — re-shape the WGC/DDA fallback + GameStream onto `session/pipeline`, then delete the
+2. **M5/M6 cleanup** — re-shape the WGC/DDA fallback + GameStream onto `session/pipeline`, then delete the
    old Windows monoliths. Low priority; AMF/QSV stays CI-only (no lab hw).
-4. **pf-vdisplay driver slot reclaim** — sustained ADD/REMOVE churn wedges the driver (`ADD →
+3. **pf-vdisplay driver slot reclaim** — sustained ADD/REMOVE churn wedges the driver (`ADD →
    0x80070490 ERROR_NOT_FOUND`): it doesn't reclaim IddCx monitor slots on REMOVE (ghost nodes accumulate).
    Recovery today is `packaging/windows/reset-pf-vdisplay.ps1`; the real fix is in the driver
    (`control.rs`/`adapter.rs`). Dev helpers `reset-pf-vdisplay.ps1` + `redeploy-pf-vdisplay.ps1` are committed.
 
 ### Resolved since the original §11 open items
 
+- **Secure desktop (the single biggest open risk; §14 STEP 6 / "biggest risk").** ✅ **Confirmed on glass
+  (owner, 2026-06-25): the IDD-push primary path captures the lock screen / UAC secure desktop AND input
+  reaches the streamed console session — "works great."** The core assertion the whole capture strategy
+  (Decision B) rested on is now proven, not asserted; the WGC-relay / secure-DDA path is no longer load-
+  bearing (kept only as a non-IddCx-hardware fallback).
 - **Driver swap-chain reuse** — the clean ownership model (`EvtCleanupCallback` + DeviceContext-owned state +
   single `Monitor` identity) is in; §2.5's reconnect-leak A/B shows **0 leaked active monitors**. The
   per-frame `CURRENT_MON_GEN` "monitor-gen bail" turned out to have been **write-only** (never wired), so the