chore: track audit-runs summary artifacts (md/csv/diff/txt/json/etc)

Snapshot of every non-log artifact under audit-runs/ from audits 003
through 058: findings.md per audit, comparison CSVs, probe diffs,
schema docs, register-dump txts, lr-trace JSONL streams, the saved
canary patch diffs, etc. ~284 files / ~52 MB total.

Excluded (per .gitignore): probe stdout/stderr/log streams (the raw
firehose), guest-memory dumps under audit-026/027/029 (4.5 GB of
.bin files; *.bin pattern added to .gitignore this commit).

Also adds the orphan audit-058-sub825070F0-activation directory that
a subagent accidentally created at project-root instead of
under xenia-rs/audit-runs/; relocated to its proper home.

Purpose: cross-machine continuity. With these summaries committed,
a fresh clone gives the next session the full per-audit context
(findings + tables + cascade predictions) without dependence on
local-only working tree.

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

audit-runs/audit-024a-canary-diff/diff.txt

@@ -0,0 +1,78 @@
+=== AUDIT-024A diff: canary (post-XAudioSubmitRenderDriverFrame trigger) vs ours (-n 500M) ===
+
+Canary log telemetry pre-dump:
+  - First XAudioSubmitRenderDriverFrame fires (triggers dump)
+  - KeReleaseSemaphore(0x828A3230, 1, 1, 0) firing repeatedly
+    (audio buffer-completion semaphore — audit-018 prediction confirmed)
+  - VdSwap, VdGetSystemCommandBuffer, VdRetrainEDRAM all firing
+  - Multiple texture loads (1280x720 k_8_8_8_8) — renderer running steady-state
+  
+Ours stats at -n 500M:
+  - instructions=500000003
+  - VdSwap=2 (plateau persists)
+  - XAudioRegisterRenderDriverClient=1 (registration ran)
+  - **XAudioSubmitRenderDriverFrame=0** (NEVER reached)
+  - **KeReleaseSemaphore=0** (still missing — canary-only export queue)
+  - NtSetEvent=3334 (matches post-KeResumeThread cascade)
+
+=== Address-by-address comparison ===
+
+addr=0x828F4070 (the [+64] singleton — audit-017 hypothesis target)
+  CANARY  +0x00: all zeros for 0x40 bytes
+  OURS    +0x00: 01 00 00 00 ... ff ff ff ff (0x10) ... 00 00 15 ec (handle@0x1e) ...
+  *** [0x828F4070+64] = 0x828F40B0 ***
+  CANARY  +0x40 (=0x828F40B0+0): 00 00 00 00 00 00 00 00 ... (zeros)
+  OURS    +0x40 (=0x828F40B0+0): ff ff ff ff 00 00 00 00 ... (sentinel -1 plus zeros)
+
+  → CANARY [0x828F40B0]+0..0x40 = ALL ZEROS
+  → OURS   [0x828F40B0]+0..0x40 = -1 sentinel at +0, then zeros
+  → AUDIT-017's claim "[0x828F4070+64]==-1 init by sub_821701c8" matches OURS exactly.
+  → CANARY's [0x828F4070] family is initialised LATER than ours (or an unrelated path).
+  → AUDIT-017's β-blocker hypothesis [+64]!=-1 is WRONG: at the post-populator moment
+     when canary is firing audio frames, [0x828F40B0]==0 in canary, NOT a non-(-1) handle.
+
+addr=0x828F4838 (audit-023's lead — early-init listener struct)
+  CANARY  +0x00: 01 01 00 00 00 00 00 00 58 45 4e 00 f8 00 00 34  ("XEN\0" + handle 0xF8000034 at +0x08)
+                +0x10: ff ff ff ff 00 00 00 00 ... 
+                +0x20: bc 36 57 40 00 00 00 08 ... (heap ptr 0xBC365740, count=8)
+                +0x34: bc 36 51 80 00 00 00 13 (heap ptr 0xBC365180, count=0x13)
+                +0x40: bc 36 51 e0 00 00 00 01 ...
+                +0x50: bc 65 c9 80 00 00 00 10 00 00 00 00 00 00 00 13 00 00 00 04
+                +0x60: 00 00 00 00 f8 00 00 2c f8 00 00 28 00 00 00 01 (kernel handles 0xF800002C, 0xF8000028)
+  OURS    +0x00: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (NO "XEN\0" magic, NO handle)
+                +0x10: ff ff ff ff 00 00 00 00 ...
+                +0x20: 40 24 a2 e0 00 00 00 08 ... (heap ptr 0x4024A2E0, count=8)
+                +0x34: 40 24 a1 a0 00 00 00 0f (heap ptr 0x4024A1A0, count=0x0F)
+                +0x40: 40 24 a2 00 00 00 00 00 ... (heap ptr 0x4024A200)
+                +0x4c: 40 54 22 40 (=0x40542240)
+                +0x50: 00 00 00 10 00 00 00 00 00 00 00 0f 00 00 00 0f
+                +0x60: 00 00 00 00 00 00 10 30 00 00 10 28 00 00 00 01 (handles 0x1030, 0x1028)
+                +0x70: ... 82 8f 40 70 00 00 00 01 ... (back-pointer to 0x828F4070!)
+
+  → BOTH have the listener struct populated.
+  → CANARY missing in OURS: "XEN\0" magic + handle 0xF8000034 at +0x08-0x10.
+     This is a kernel-handle dispatch type-tag, NOT data-pointer divergence.
+  → Heap pointers differ (0xBC36xxxx vs 0x4024xxxx) — different allocator,
+     not bug-relevant.
+  → Counts and handles all populated in ours; back-pointer to 0x828F4070 present.
+
+addr=0x828A3230 (audio buffer-completion semaphore — KeReleaseSemaphore target)
+  CANARY  +0x00: 05 00 00 00 00 00 00 00 58 45 4e 00 f8 00 00 70  (state=5, "XEN\0" + handle 0xF8000070)
+                +0x10: 00 00 00 06 01 00 00 00 ... 
+                +0x14: 01 00 00 00 (count=1, the released semaphore — was 0)
+                +0x18: 00 00 00 00 58 45 4e 00 f8 00 00 80 ("XEN\0" + handle 0xF8000080)
+                +0x28: 01 00 00 00 ("XEN\0" + handle 0xF800007C)
+                +0x38: be 62 8e dc 1f ca 70 00 (likely callback ptr or last-completed timestamp)
+  OURS    not dumped — added to extra-watch-list for next session.
+
+addr=0x828F48B0+0x24 = 0x828F3EC0 (the dispatcher addr for handle 0x100c per audit-003)
+  CANARY  +0x24: 82 8f 3e c0 (the dispatcher for the 0x100c worker)
+  → confirms the singleton-pool layout in canary too, populated identically.
+  → OURS not dumped — added to next-session.
+
+=== Conclusions ===
+
+Outcome (ii) — **`[0x828F4070+64]` is STILL ZERO in canary at first XAudioSubmitRenderDriverFrame**.
+The audit-017 β-blocker hypothesis ([+64] becoming non-(-1)) is FALSIFIED.
+The actual divergence at this boot point: canary's `"XEN\0" + 0xF8000034` magic at 0x828F4838+0x08
+is not present in ours (already known from audit-023, confirmed stable).