docs(windows-client): correct the WinUI 3 record — reactor IS used (PR #4499)

The winit-commit docs claimed "Reactor rejected, no SwapChainPanel hatch" — that was wrong.
windows-rs PR #4499 added the SwapChainPanel widget; the client now uses WinUI 3 via
windows-reactor. Update CLAUDE.md M4, the bootstrap-doc status banner (reactor integration:
pinned git dep, CARGO_WORKSPACE_DIR, App-SDK build.rs, LL-hook stream input), and the
docs-site clients page (WinUI 3, launch-and-pick-a-host).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/windows-client-bootstrap.md

@@ -5,28 +5,42 @@ and live-validated on a real RTX 4090; the client is the remaining piece. This d
 starting point: the locked decisions, the reference code to port, the stack swaps, the dev loop, and
 the gotchas. Read it top to bottom, then start at **Phase 1** (de-risk Reactor first).
 
-## Status — stage 1 landed (2026-06-15)
+## Status — WinUI 3 client landed (2026-06-15)
 
 The client is implemented in `crates/punktfunk-client-windows` (binary `punktfunk-client`) and is
-**build + clippy + fmt + test green on `x86_64-pc-windows-msvc`** (built on the dev VM). Done: winit
-window + **Direct3D11 flip-model swapchain** present (WARP on the GPU-less box; runtime-compiled
-fullscreen-triangle shaders, Contain-fit letterbox), **FFmpeg software HEVC decode**, **WASAPI** render
-+ mic capture, keyboard/mouse/wheel capture (physical-`KeyCode`→VK, click-to-capture), **SDL3**
-gamepads, `mdns-sd` discovery, and the full trust surface (identity + TOFU + SPAKE2 PIN over
-`--connect`/`--discover`/`--pair`/`--headless`).
+**build + clippy + fmt green on `x86_64-pc-windows-msvc`** (built on the dev VM). It is the **WinUI 3**
+client this doc planned: native chrome (host list, settings, in-app SPAKE2 PIN pairing) + the video on
+a **`SwapChainPanel`**, all in pure Rust.
 
-- **Reactor was evaluated and rejected** (a research pass + the points below): windows-rs Reactor
-  ships **no `SwapChainPanel` and no `ISwapChainPanelNative::SetSwapChain` escape hatch**, so it
-  cannot host a DXGI presenter. The client uses the doc's sanctioned fallback — **winit + a raw
-  D3D11 swapchain on the HWND** — which builds and runs against WARP on the GPU-less VM. A native
-  WinUI look would need the `SwapChainPanel` hatch to land upstream first.
-- **Build gotcha (in addition to the ASCII *output* path below):** `CARGO_HOME` itself must be on an
-  **ASCII path** (e.g. `C:\Users\Public\.cargo`). SDL3's `build-from-source` compiles a precompiled
-  header whose `#include` embeds the registry source path; the `ü` in the dev box's username makes
-  MSVC's PCH/structured-output fail (`MSB8084` / `C4828`). Set `CARGO_HOME=C:\Users\Public\.cargo`.
-- **Still pending:** live host validation (the dev box has no GPU → glass-to-glass numbers defer to
-  the RTX box), **D3D11VA hardware decode** + **10-bit/HDR present**, a native host-list/settings
-  GUI (CLI flags for now), and RAWINPUT relative-mouse pointer-lock. Phases 4–7 below are the map.
+- **Reactor is viable after all — it is what we use.** The locked decision held. windows-rs
+  [PR #4499](https://github.com/microsoft/windows-rs/pull/4499) (merged 2026-06-01) added a
+  `SwapChainPanel` widget to **`windows-reactor`** with `set_swap_chain` over
+  `CreateSwapChainForComposition` — so a DXGI presenter *can* be hosted. (An earlier read that Reactor
+  had no swapchain hatch was wrong/stale.) The UI is a declarative React-like tree
+  (`App::new().render(app)`, `use_state`/`use_resource`/`use_effect` hooks, `list_view`/`text_box`/
+  `combo_box`/`content_dialog`/`button`/`ToggleSwitch`); the video page is `swap_chain_panel()
+  .on_ready(|p| p.set_swap_chain(&sc))` driven by `on_rendering`. **`present.rs`** owns the D3D11
+  composition swapchain (WARP fallback, runtime shaders, Contain-fit) — the same renderer, bound to
+  the panel instead of an HWND.
+- **windows-reactor is unpublished** (`version 0.0.0`) and fast-moving — depend on it as a **git dep
+  pinned to a commit** (`b4129fcc`), and pin the `windows` crate to the **same commit** so the
+  `IDXGISwapChain1` you pass to `set_swap_chain` satisfies reactor's `windows_core::Interface`. Its
+  `build.rs` downloads the Windows App SDK NuGets (Foundation/Interactive/Runtime) and stages the
+  bootstrap DLL + `resources.pri` next to the exe; it **`.unwrap()`s `CARGO_WORKSPACE_DIR`**, so set
+  it in the build env (`CARGO_WORKSPACE_DIR=C:\Users\Public\punktfunk`). It writes `/temp` + `/winmd`
+  to the workspace root (gitignored). The App SDK runtime must be installed to *run*.
+- **Stream input is Win32 low-level hooks**, not XAML: reactor exposes only keyboard *accelerators* +
+  pointer *button-state* (no raw key-down/up, no pointer position, no wheel), insufficient for a game
+  stream. `input.rs` installs `WH_KEYBOARD_LL`/`WH_MOUSE_LL` on the stream page (uninstalled on exit),
+  maps the pointer through the window client rect, sends native VK + abs mouse + wheel, with a
+  Ctrl+Alt+Shift+Q capture toggle. (A future alternative: generate `Microsoft.UI.Xaml.UIElement`
+  bindings from the staged winmd and subscribe to `KeyDown`/`PointerMoved` — scoped to the panel.)
+- **Build gotcha:** `CARGO_HOME` must be on an **ASCII path** (`C:\Users\Public\.cargo`). SDL3's
+  `build-from-source` PCH embeds the registry source path; the `ü` in the dev box's username makes
+  MSVC fail (`MSB8084` / `C4828`).
+- **Still pending:** **on-glass validation** — the dev VM is headless / SSH Session 0, so the WinUI
+  window can't show there; validate over RDP or on the RTX box. Then **D3D11VA hardware decode** +
+  **10-bit/HDR present**, RAWINPUT relative-mouse pointer-lock, and a per-host speed test in the UI.
 
 ## What we're building