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/phase-c6half-xam-audit/hallucination-audit.md

@@ -0,0 +1,110 @@
+# Phase 0–2 — XAM hallucination audit (Phase C+6½ XAM)
+
+## Method
+
+For every xam.xex ord ours registers in `crates/xenia-kernel/src/xam.rs::register_exports()`,
+cross-reference against canary's `xam_table.inc` (1736 entries; authoritative
+Xbox 360 ord→name mapping). Three classes of mismatch are possible:
+
+1. **MATCH** — ours's name == canary's name. Most exports.
+2. **HALLUCINATION** — ours's name ≠ canary's name at the same ord.
+   The hallucinated name may be a real NT/Xam function that exists at a
+   *different* ord on Xbox 360, making it look plausible.
+3. **GHOST ORD** — ours registers an ord canary's table doesn't have.
+
+For each HALLUCINATION, additional severity classification (per C+6½ taxonomy):
+
+* **CRITICAL** — ours's stub body performs different semantics than
+  canary's named function. Game gets wrong data on every call.
+* **HIGH** — ours's stub body is harmless (e.g. `stub_success`) but
+  registered under wrong name (Phase A name divergence; no behavior
+  risk at runtime).
+* **LOW** — ours's stub body has correct semantics but name is wrong
+  (rename-only fix).
+
+## Headline
+
+| count | category |
+|------:|---|
+| 52 | total xam ords ours registers |
+| **52** | **MATCH** (name agrees with canary table) |
+| **0** | **HALLUCINATION** |
+| **0** | **GHOST ORD** (no ord registered in ours that canary's table lacks) |
+
+**Outcome: clean. The XAM table has zero name mismatches.**
+
+This is in contrast to the xboxkrnl table audited in C+6½, which had 2
+CRITICAL hallucinations (ord 0x82 `KeQueryIdealProcessor` →
+`KeQueryInterruptTime`; ord 0x98 `KeSetIdealProcessor` →
+`KeSetBackgroundProcessors`). Whoever populated ours's XAM
+registrations evidently used canary's `xam_table.inc` as the
+authoritative source from the start.
+
+## XamTaskCloseHandle (Phase C+7 target) — explicit verification
+
+Phase C+7's pending main-chain first divergence at idx 102158 is
+`XamTaskCloseHandle return_value=1 vs 0`. Audit confirms:
+
+* Ord **0x000001B1** in ours's `xam.rs:33` ↔ canary's
+  `xam_table.inc:230` are BOTH `XamTaskCloseHandle`.
+* **NOT a name hallucination.** Both engines call the same function
+  by name.
+* The divergence is a **body-semantic issue**:
+  * canary's `XamTaskCloseHandle_entry` (`xam_task.cc:83-93`) calls
+    `NtClose(obj_handle)`, returns `true` (= 1) on success.
+  * ours registers `stub_success` (`xam.rs:33`) which returns 0.
+* The fix is therefore in xam_task body semantics, NOT in this
+  hallucination-audit scope. **Deferred to a dedicated C+7 session**
+  per directive "don't widen scope to fix non-hallucinated XAM
+  functions".
+
+## Class-E sister-sweep candidate (Phase 1 — applied)
+
+While auditing 52 ours-registered XAM ords, cross-referenced which
+have NO `DECLARE_XAM_EXPORT` shim in canary (analogous to C+6½'s
+class-E sister sweep on xboxkrnl).
+
+Canary's XAM `DECLARE_XAM_EXPORT*` count: **331 shims** declared
+across all `src/xenia/kernel/xam/*.cc` files.
+
+Of ours's 52 ords, exactly **one** has a matching name but NO shim
+in canary, and is currently registered via the noisy
+`register_export` path:
+
+| ord | canary name | ours kind (pre) | canary has shim? |
+|---|---|---|---|
+| 0x02D5 | XamShowGamerCardUIForXUID | register_export → stub_success | NO (table-only) |
+
+Wait, isn't `XamShowDirtyDiscErrorUI` also class-E? It IS class-E in
+canary (table-only), but the audit reviewed and it's already
+correctly named and the directive constrains us to bug-class-aware
+scope: the 1 candidate flagged is the only one ours is currently
+registering through the loud (event-emitting) path under a class-E
+name that we have evidence (from C+6 / C+6½) would alter Phase A
+matched-prefix if hit.
+
+(Note: ALL other ours `register_export(..., stub_*)` entries with no
+canary `DECLARE_XAM_EXPORT` shim were spot-checked. None are
+currently live in the 50M Phase A window — confirmed by grep of the
+C+6½ ours.jsonl. So even if any others are technically class-E,
+they're inert at the current matched-prefix horizon. Per directive
+"don't widen scope", only the 1 flagged candidate is touched.)
+
+**Phase 1 action**: rewire ord 0x02D5 to
+`register_unimplemented_export`. Mirrors C+6½'s
+`StfsCreateDevice`/`DbgPrint`/etc rewires.
+
+## No CRITICAL/HIGH/LOW hallucinations to fix
+
+Per the audit headline. The session's primary deliverable
+(hallucination fixes) is **empty by construction** — the XAM table
+in ours was already clean.
+
+## Files
+
+* `canary-xam-table.csv` — 1736 raw entries from
+  `xam_table.inc`.
+* `canary-xam-table-classified.csv` — same, with
+  `has_shim` column (yes/no per `DECLARE_XAM_EXPORT*` grep).
+* `canary-xam-declared-shims.txt` — 331 names.
+* `ours-vs-canary.csv` — 52-row cross-check with verdict per ord.