docs: refresh README/CLAUDE status; roadmap pairing-hardening + SudoVDA Windows

- README: replace the stale M0/M2-in-flight status with reality — M1 hardened, M2
  GameStream host live to stock Moonlight, M3 punktfunk/1 validated, M4 Apple first
  light, web console + unified host; FFmpeg 7/8; Bazzite-deployed. Layout adds
  web/, packaging/, native_pairing, dualsense.
- CLAUDE: protocol-growth item now reflects the unified host + web-console native
  pairing (done) and flags the next steps; layout updated.
- roadmap §7 Windows: de-risked via SudoVDA (the Sunshine Virtual Display Adapter) —
  no self-signed kernel IDD needed; the virtual-display backend drops XL→M.
- roadmap §8 (new) Pairing & trust hardening: mandatory PIN pairing by default
  (TOFU-open is insecure on a LAN) + delegated pairing approval (an already-paired
  device approves a new one, no out-of-band PIN).
- windows-host.md: SudoVDA path throughout (status, table, phasing, effort M not L).

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

docs/windows-host.md

@@ -1,12 +1,15 @@
 # Windows as a host — feasibility & scoping
 
-**Status: scoped, deferred.** A Windows host is architecturally an *"add a backend"* job, not a
-parallel port — but it is a **large** implementation effort across five GPU/driver subsystems, and
-the project's headline feature (a per-client *virtual* output at the client's exact mode) has **no
-user-mode Windows API**: it needs a signed kernel-mode Indirect Display Driver (IDD). This doc
-records what it takes so the work can be picked up deliberately later.
+**Status: scoped, deferred — but de-risked.** A Windows host is architecturally an *"add a backend"*
+job, not a parallel port. The one thing that used to make it **large** — the per-client *virtual*
+output, which has no user-mode Windows API and seemingly needed a self-signed kernel Indirect
+Display Driver (IDD) — is **solved by reusing [SudoVDA](https://github.com/VirtualDrivers), the
+Sunshine Virtual Display Adapter**: a pre-built, signed IDD that creates virtual displays at
+arbitrary `WxH@Hz` on demand. We install it and drive its control interface; **no driver to write or
+WHQL-sign.** That turns the headline feature from XL into a medium backend. This doc records what's
+left so the work can be picked up deliberately.
 
-(Grounded in a 4-agent read of the host crate, 2026-06-10.)
+(Grounded in a 4-agent read of the host crate, 2026-06-10; SudoVDA path added 2026-06-11.)
 
 ## What's already done for us
 
@@ -33,7 +36,7 @@ all reuse the existing trait.
 | Subsystem | Linux today | Windows equivalent | Effort | Notes |
 |---|---|---|---|---|
 | **Capture** | xdg ScreenCast portal → PipeWire (dmabuf) | **DXGI Desktop Duplication** (or Windows.Graphics.Capture) → D3D11 texture | M | DXGI gives a GPU `B8G8R8A8` texture directly |
-| **Virtual display** | KWin/Mutter/Sway/gamescope protocols | **Indirect Display Driver (IDD)** — kernel UMDF mini-driver | **XL** | ⚠️ **the blocker**: no user-mode API; C++ driver + **code signing** (test-sign or WHQL). Fallback: capture an existing monitor (loses the native-resolution feature) or a borderless window |
+| **Virtual display** | KWin/Mutter/Sway/gamescope protocols | **SudoVDA** (pre-built signed IDD) — install + drive its control API to add/remove a `WxH@Hz` virtual monitor per session | **M** | ✅ **no longer the blocker**: SudoVDA is the same IDD Sunshine ships, so no driver to author or sign. The `VirtualDisplay` backend = enable the adapter, create a monitor at the client's mode, capture it (DXGI), tear it down on session end. Fallback if SudoVDA is absent: capture an existing monitor (loses native-resolution) |
 | **Encode** | `ffmpeg-next` NVENC, CUDA hwframes | Media Foundation H.264/HEVC/AV1, **or** NVENC SDK direct with a D3D11 device context (`AVD3D11VADeviceContext`) | M–L | `encode.rs` AU/codec logic + NVENC option strings are portable; only the hwdevice + frame-pool glue swaps |
 | **Zero-copy bridge** | dmabuf → EGL/Vulkan → CUDA | D3D11 texture → NVENC (shared texture / `cudaImportExternalMemory` + D3D12 fence) | M | **optional** — a portable CPU-copy path already exists, so v1 can skip this |
 | **Input (ptr/kbd)** | libei (RemoteDesktop portal) / wlr protocols | **SendInput** (`keybd_event`/`mouse_event`) | S | the VK→evdev table just becomes VK→`VIRTUAL_KEY` (already Win32-native) |
@@ -42,9 +45,9 @@ all reuse the existing trait.
 | **Virtual mic** | PipeWire `Audio/Source` | virtual audio device (VB-Cable-style WDM driver) or WASAPI render-to-fake-device | M | needs a driver or a bundled 3rd-party cable |
 | **`sendmmsg` batching** | `gamestream/stream.rs` | already has a `cfg(not(linux))` per-packet fallback | — | nothing to do |
 
-**Rough total: ~2,000–4,000 LOC of new Rust** (+ a C++ IDD driver if the virtual-display feature is
-kept), spread over capture/encode/vdisplay/input/audio. Every reader rated the overall effort
-**large**; the input+audio layer alone is *medium*.
+**Rough total: ~2,000–4,000 LOC of new Rust** (no C++ driver — SudoVDA is reused as-is), spread over
+capture/encode/vdisplay/input/audio. With the driver problem solved, the overall effort is now
+**medium**; the input+audio layer alone is *small–medium*.
 
 ## Recommended phasing (when picked up)
 
@@ -52,17 +55,19 @@ kept), spread over capture/encode/vdisplay/input/audio. Every reader rated the o
    Desktop Duplication) → Media Foundation/NVENC encode → SendInput + WASAPI loopback. This proves
    the whole stack on Windows with the smallest surface, reusing all of core/QUIC/GameStream/mgmt.
    It loses the per-client native-resolution output but is a working Windows host quickly.
-2. **Phase 1 — input + audio parity.** ViGEm gamepads + rumble; WASAPI virtual mic; D3D11→NVENC
+2. **Phase 1 — the virtual display via SudoVDA.** A `VirtualDisplay` backend that enables SudoVDA,
+   creates a monitor at the client's exact `WxH@Hz`, captures it (DXGI), and tears it down on session
+   end — restoring punktfunk's headline feature with **no driver authoring or signing**. (Ship/guide
+   the SudoVDA install as a host prerequisite, like the udev rule on Linux.)
+3. **Phase 2 — input + audio parity.** ViGEm gamepads + rumble; WASAPI virtual mic; D3D11→NVENC
    zero-copy.
-3. **Phase 2 — the virtual display (IDD).** The XL piece: a signed Indirect Display Driver that
-   surfaces a client-sized monitor, captured via DXGI. This restores punktfunk's differentiator on
-   Windows. Gated on solving driver signing/distribution.
 
 ## Why it's deferred (not started now)
 
-- It's **large**, and the virtual-display blocker (IDD) is a kernel driver + signing problem
-  outside Rust — not "somewhat manageable" as a side effort.
-- None of it is **buildable or testable on the Linux dev box** — it would be unvalidated code.
+- The remaining work is **medium** and mechanical, but **none of it is buildable or testable on the
+  Linux dev box** — it would be unvalidated code until there's a Windows box in the loop.
+- SudoVDA removed the hard blocker (the signed kernel driver); what's left is a backend port, picked
+  up whenever a Windows target is in scope.
 
 The architecture is ready whenever the work is scheduled; this doc + the clean trait boundaries are
 the down payment. Start at **Phase 0** for the fastest path to a working Windows host.