handoff: VSync/event-wedge fixes + iterate 2.A–2.BC research notes

Source changes (dormant parity infra, retained from iterate 2.AI/2.AO):
- xenia-kernel/exports.rs: nt_create_event manual_reset polarity +
  related event wiring
- xenia-gpu/mmio_region.rs: D1MODE_VBLANK_VLINE_STATUS hardcode parity

Also lands the audit-runs/ analysis notes (.md/.txt/.json digests) for the
iterate 2.x VSync/0x10e8/0x1004 wedge investigation. Raw trace dumps
(.jsonl/.gz/.csv/.stdout) and agent worktrees (.claude/) are gitignored as
regenerable local artifacts — see memory + HANDOFF for the running findings.

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

audit-runs/review-a-step1-force-spawn/progression-result.md

@@ -0,0 +1,70 @@
+# Progression-metric result — Review A Step 1
+
+**Date**: 2026-05-27
+**PRIMARY gate**: `swaps > 1 OR draws > 0 OR unique_render_targets > 0`.
+
+## Composite progression score (per Review A Q5)
+
+```
+score = 1*swaps + 10*draws + 100*unique_render_targets
+```
+
+| Run | swaps | draws | unique_RT | score |
+|----:|------:|------:|----------:|------:|
+| OFF-1 | 1 | 0 | 0 | **1** |
+| OFF-2 | 1 | 0 | 0 | **1** |
+| OFF-3 | 1 | 0 | 0 | **1** |
+| ON-1  | 1 | 0 | 0 | **1** |
+| ON-2  | 1 | 0 | 0 | **1** |
+| ON-3  | 1 | 0 | 0 | **1** |
+
+- **OFF mean**: 1.0
+- **ON mean**: 1.0
+- **Δ (ON - OFF)**: 0
+
+## PRIMARY gate verdict
+
+**FAIL.** No swap beyond the boot-init swap; no draws; no render
+targets.  The crowbar fires successfully (4/4 workers spawned and
+resumed) but the workers fault ~159 instructions in on the unmapped
+canary VA `0xBCE25640`, before they can advance the wedge or emit
+PM4 draw commands.
+
+## What "winning" would have required
+
+Per `shortest-path-roadmap.md` §"What 'winning' looks like":
+
+```json
+{
+  "draws": >= 1,
+  "swaps": >= 2,
+  "unique_render_targets": >= 1
+}
+```
+
+reproducible across 3 cold runs.  Observed: all 0/1/0 across 6 runs
+(3 OFF + 3 ON).  Matches v3's 2026-05-21 outcome bit-for-bit at the
+progression-metric level (Δ = 0).
+
+## Why the crowbar didn't unblock
+
+Per v3 `investigation.md` §"The fault (v3)" and re-validated this
+session: the worker entry stubs at `0x82506528/58/88/B8` dispatch
+through `vtable[35..38]` to fns like `sub_82506E08`, `sub_82508520`,
+etc.  Those fns immediately load `[ctx+44]` into r3 expecting a
+secondary-object pointer (per canary's runtime ctx state).  In v3 the
+secondary-object pointer was captured as `0xBCE25640` and installed
+verbatim per Option γ.  In ours's address space, `0xBCE25640` is
+not allocated (ours's allocator namespace is `0x4000_0000..0x6FFF_FFFF`).
+Reading `[0xBCE25640]` returns 0 → CTR=0 → `bctrl` faults at PC=0.
+
+The fault is bit-stable across 3× cold ON runs (deterministic
+scheduling under `--gpu-thread`).
+
+## Matched-prefix shift under crowbar (informational only — NOT a gate)
+
+Matched-prefix vs canary was NOT computed in this session because the
+crowbar fundamentally alters guest control flow (introduces 4 host-spawned
+threads with synthesised ctx state).  Per reading-error #23, matched-prefix
+regression under crowbar-on is EXPECTED and not a failure indicator —
+the PRIMARY gate is progression metric, not matched-prefix.