docs(design): trim shipped plans, consolidate cluster, add index

Much of design/ described work that has since shipped. Trim each doc to
its durable rationale + still-open items (the code is the source of truth
for shipped detail; git history holds the full originals).

- Shipped plans -> status stubs: stats-capture, gamestream-host-plan,
  apple-stage2-presenter, windows-service.
- Trimmed completed-out / open-kept: implementation-plan, hdr-pipeline,
  host-latency, gpu-contention (fixed stale status table), game-library,
  linux-setup (fixed m0->spike + stale zero-copy claim),
  session-aware-host-followups, windows-client-bootstrap,
  windows-dualsense-{scoping,game-detection}, windows-virtual-display,
  security-review (per-finding status table; #12 still open),
  apollo-comparison (shipped backlog collapsed to one-liners).
- Windows-host cluster consolidated: windows-host.md -> redirect into
  windows-host-rewrite.md (whose stale scorecard is corrected -- goal1 is
  merged, M4 done); windows-secure-desktop.md archived (now a fallback
  behind IDD-push primary).
- Kept evergreen: ci.md, gamescope-multiuser.md, windows-build-and-packaging.md.
- New design/README.md: per-doc status table + consolidated open-items
  roll-up so nothing is tracked in only one buried doc.
- Repoint 5 code comments to the archived secure-desktop doc path.

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

design/dualsense-haptics.md

@@ -3,14 +3,16 @@ title: "DualSense Haptics"
 description: "Feasibility and scoping for audio-driven DualSense haptics."
 ---
 
+> **Status:** Audio-driven advanced (voice-coil) haptics — **NO-GO, DEFERRED.** The reachable
+> HID work it scoped instead — **adaptive triggers + two-motor rumble** — **SHIPPED** (commit
+> `59edeed`; see CLAUDE.md gamepad section, `inject/dualsense.rs`). This doc is trimmed to the
+> deferral rationale (the three walls) + the conditions that would trigger a revisit.
 
-**Status: scoped, NO-GO for now (deferred).** Advanced voice-coil haptics on the DualSense are
-driven by the controller's **USB audio interface** (4-channel surround, the back two channels carry
-the haptic waveform), *not* by HID reports. Emulating that on a Linux host and faithfully replaying
-it on the Apple client both hit hard walls, and the supply of software that actually *emits* these
-haptics on a Linux host is essentially zero. We defer the audio-haptics feature and instead land the
-parts of "really supporting the DualSense" that *are* reachable: **adaptive triggers (HID) and
-two-motor rumble.**
+Advanced voice-coil haptics on the DualSense are driven by the controller's **USB audio interface**
+(4-channel surround, the back two channels carry the haptic waveform), *not* by HID reports.
+Emulating that on a Linux host and faithfully replaying it on the Apple client both hit hard walls,
+and the supply of software that actually *emits* these haptics on a Linux host is essentially zero.
+We defer the audio-haptics feature.
 
 (Grounded in a 4-agent feasibility read — host USB-gadget viability, DualSense audio descriptors,
 Linux game demand, Apple client render path — 2026-06-10.)
@@ -72,22 +74,6 @@ Even with a captured waveform, the primary client (macOS/iOS) can't render it we
 - There is **no public macOS API** to route CoreAudio to the DualSense's channels 3–4. Doing it
   anyway means private/reverse-engineered APIs that break across OS updates.
 
-## What we *can* ship instead ("really supporting the DualSense" minus audio haptics)
-
-The HID DualSense we built is the foundation, and the high-value parts are within reach:
-
-1. **Adaptive triggers — GO.** `dualsense.rs` already parses the L2/R2 trigger effects out of HID
-   output report `0x02`. Finishing this is the paused HID work: route them over the `0xCD`
-   HID-output back-channel and render on the client. This delivers the headline "DualSense feel"
-   (trigger resistance/weapon tension) for any source that emits it — and it's pure HID, no audio
-   interface, no kernel rebuild.
-2. **Two-motor rumble — already done.** Parsed host-side; the Apple client already has
-   `nextRumble()`. Wire it to `GCDeviceHaptics`/`CHHapticEngine` as discrete patterns (API-clean,
-   no private APIs).
-3. **LED / player-LED / touchpad / motion** — already parsed; finish the `0xCC`/`0xCD` routing.
-
-This is the resume-able HID DualSense Phase C/D/E work — it stands on its own and was never blocked.
-
 ## Conditions for a future GO on audio haptics
 
 Revisit if **all three** change:
@@ -103,9 +89,9 @@ Revisit if **all three** change:
 Until then the cost/benefit is upside-down: three hard subsystems (kernel, USB gadget, audio
 routing) to serve ~5–10 Proton titles, rendered lossily on the one client we ship.
 
-## Recommendation
+## Open items
 
-**Defer audio-driven advanced haptics. Land adaptive triggers (HID) + rumble instead** — that's the
-reachable 80% of "really supporting the DualSense," needs no kernel work, and the parsing is already
-written. Keep this doc as the down payment for the audio-haptics feature whenever the three
-conditions above are met.
+- **Audio-driven advanced (voice-coil) haptics — DEFERRED.** Explicitly blocked until **all three**
+  "Conditions for a future GO" above are met (a real DualSense to capture the UAC layout, a host UDC
+  or grown Linux haptic-title supply, and a client that can render PCM haptics). This doc is the down
+  payment to revisit then.