docs(windows-host): KeyedMutexGuard done + record the on-glass build validation

Goal 3: the IDD-push hot-loop KeyedMutexGuard (6585643) landed, and the whole
session's Windows + driver work is now ON-GLASS BUILD-VALIDATED on the RTX box —
host clippy -D warnings clean + driver build clean (the gate that surfaced + got
11 lints fixed in bd05bc8). Only the deferred host P0 lints + the deliberately-
left service.rs SCM-handler event smuggling remain, plus an optional latency A/B.

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

docs/windows-host-rewrite.md

@@ -34,7 +34,7 @@ which kept the live-validated host working at every step. The driver, by contras
 |---|---|---|
 | **Goal 1** — clean, layered host architecture | ✅ **DONE** | `config.rs` (`HostConfig`), `session_plan.rs` (`SessionPlan`), `SessionContext`, `windows/`+`linux/` confinement (`38c68c3`), `VirtualDisplayManager` (§2.5), `EncoderCaps` (`0ccd0fe`) |
 | **Goal 2** — drop every trace of SudoVDA | ✅ **DONE** | reach-in decoupled (F1: `d638a93`/`e60cda3` → `win_adapter`/`win_display`), then the `sudovda.rs` backend + the dual-backend select **deleted** (this branch) — pf-vdisplay is the sole Windows virtual-display backend |
-| **Goal 3** — minimize `unsafe` + P0 lints | 🟡 **PARTIAL** | driver `deny(unsafe_op_in_unsafe_fn)` (`a755d6e`); **`OwnedHandle`/RAII rollout** — `idd_push.rs` (`011607e`, also a view-leak fix) + `service.rs` child/job (`4c95ba7`) + the 3 gamepad backends via shared `gamepad_raii.rs` (`e5c2b4e`), on top of `manager.rs`/`pf_vdisplay.rs`; **driver `pod_init!`** (`bf57704`, 27→1). Remaining: host-crate P0 lints (deferred — high churn, low value), the `service.rs` SCM-handler event smuggling, the on-glass-gated `KeyedMutexGuard` hot-loop RAII |
+| **Goal 3** — minimize `unsafe` + P0 lints | 🟡 **PARTIAL** (**box-validated**) | driver `deny(unsafe_op_in_unsafe_fn)` (`a755d6e`); **`OwnedHandle`/RAII rollout** — `idd_push.rs` (`011607e`, view-leak fix) + `service.rs` child/job (`4c95ba7`) + the 3 gamepad backends via shared `gamepad_raii.rs` (`e5c2b4e`) + the IDD-push `KeyedMutexGuard` hot loop (`6585643`); **driver `pod_init!`** (`bf57704`, 27→1). **On-glass clean: host clippy `-D warnings` + driver build** (RTX box; `bd05bc8` fixed 11 lints the gate surfaced). Remaining: host-crate P0 lints (deferred — churn>value), the `service.rs` SCM-handler event smuggling (deliberately left) |
 | **M0** — proto ABI + driver toolchain + `/INTEGRITYCHECK` + `iddcx` | ✅ **DONE** | `pf-driver-proto`; vendored `windows-drivers-rs` 0.5.1; `clear-force-integrity.ps1`; CI-green |
 | **M1** — new IddCx driver, first light + HDR | ✅ **DONE (on-glass)** | STEP 0–8 (`d7a9fbf`…`cd59151`); HDR live ("Mac connects WITH HDR", `6399d28`) |
 | **M2** — IDD-push capture + NVENC, glass-to-glass | ✅ **DONE (on-glass)** | 5120×1440@240 HDR zero-copy; integrated into the host path |
@@ -234,14 +234,21 @@ These are expensive empirical wins; keep them intact when touching the code:
    duplicated `create_shm_section` + three hand-written `Drop`s). **Remaining (deliberately left):** the
    `service.rs` `AtomicIsize` STOP/SESSION events — smuggled into the C SCM handler, a separate riskier
    redesign. `manager.rs`/`pf_vdisplay.rs` already used the pattern.
-6. **Driver unsafe levers** (the driver is already `deny`-clean with per-site SAFETY; these *reduce count*):
+6. **Hot-loop `KeyedMutexGuard` ✅ done** (`6585643`) — the IDD-push consume loop's hand-written
-   ✅ **`pod_init!` macro done** (`bf57704`, 27 `mem::zeroed` → 1). **Skipped `ThreadBound<T>`** — not a clean
+   `AcquireSync`/`ReleaseSync` (with its "don't `?`-return between them or you leak the lock + stall the
-   win (each `unsafe impl Send` wraps a distinct type; consolidating churns every access for no real safety
+   driver" caveat) is now a RAII guard scoped to the convert/copy block: same release point (latency
-   gain over the per-struct `// SAFETY:`). **Scratched the IOCTL dispatcher** — `control.rs`'s
+   unchanged), but leak-proof on any early return. **Driver `pod_init!` ✅** (`bf57704`, 27 `mem::zeroed` →
-   `read_input<T>`/`write_output_complete<T>` are already generic helpers with minimal, documented unsafe;
+   1). **Skipped `ThreadBound<T>`** (each `unsafe impl Send` wraps a distinct type — churn, no real gain) and
-   re-factoring would be churn, not reduction. **Remaining (on-glass-gated):** a `KeyedMutexGuard`/
+   **scratched the IOCTL dispatcher** (`control.rs`'s `read_input<T>`/`write_output_complete<T>` are already
-   `AcquiredSurface` RAII for the frame-transport hot loop — perf-sensitive, needs an on-glass latency check,
+   generic with minimal unsafe).
-   so held rather than rushed blind.
+
+**On-glass build validation (RTX box, 2026-06-26).** Built this branch on the box in an isolated worktree:
+**host `cargo clippy -p punktfunk-host --features nvenc -D warnings` = CLEAN**, **driver `cargo build` =
+CLEAN** — validating the whole session's Windows + driver work on real hardware. The clippy gate (which the
+goal1/§2.5 work never ran — it used `cargo check`) surfaced + fixed 11 lint issues (`bd05bc8`: 9 redundant
+`as *mut c_void`, an `if_same_then_else`, an `unused_unsafe` in `pod_init!`). Remaining only a runtime
+**latency A/B** for the `KeyedMutexGuard` (provably equivalent — same release point) if a deeper check is
+wanted.
 7. **D1-host P0 lints — deferred (low value / high churn).** A crate-wide `#![deny(unsafe_op_in_unsafe_fn)]`
    produced 100+ FFI-wrap sites across the Linux modules; it *wraps* unsafe (discipline) rather than
    reducing it and doesn't improve stability, so it was deprioritized vs the `OwnedHandle`/RAII reductions