docs: record item 4.6 fix, aarch64 BYE crash fix, and DoE campaign in CHANGELOG/ROADMAP

CHANGELOG.md: new 2026-08-18 entry for today's work, plus a post-split
note explaining the branch-tag convention no longer applies (this repo
is now LithosAnanke-only, master as sole production line).

docs/lithosananke/ROADMAP.md: M7.1 section predates all the real
Tripod/Stadium/ACL work and was silently stale -- added a dated
redirect to FABRIC.md/FABRIC-2.md (matching the doc's own existing
pattern for the M8 section) rather than rewriting the whole section.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -4,7 +4,45 @@ Milestone-level achievements only — not a commit log. For full history see
 `git log` on the relevant branch. Two products share this file:
 **StarForth** (hosted FORTH-79 VM, `master`) and **LithosAnanke** (bare-metal
 UEFI kernel, `lithosananke`). Entries are tagged by which branch(es) they
-landed on.
+landed on. **Post-split note (2026-08-18):** the combined monorepo this
+convention describes has been split into two separate repositories;
+LithosAnanke now lives here with `master` as its sole production line (no
+`lithosananke` branch in this repo). Entries below this note carry no
+branch tag for that reason.
+
+## 2026-08-18 — Item 4.6 (Artemis Stadium migration) quota-ordering bug fixed; aarch64 `BYE` crash fixed; full 3-arch DoE campaign clean
+
+Artemis's 30-rep surface stress campaign (item 4.6, migrating her block-heat
+arena to Stadium admission-on-allocate) was failing 100% of trials on all
+three architectures. Root-caused to `capsule_birth.c`: `stadium_grant_quota()`
+ran after IDENTITY exec, but Artemis's `init.4th` auto-runs the stress
+campaign as part of that same IDENTITY exec, so every `STADIUM-ADMIT` call
+hit a nonexistent quota slot and refused unconditionally. Moved the grant
+before IDENTITY exec. Verified 30/30 reps PASS on amd64, aarch64, and
+riscv64 (was 30/30 FAIL on all three).
+
+Separately fixed a long-standing aarch64-only crash on `BYE` (present since
+at least 2026-08-08): `arch_cold_reset()` issued PSCI `SYSTEM_RESET` via
+`smc #0`, but this QEMU/AAVMF boot configuration has no genuine EL3/TrustZone
+secure monitor to answer an SMC — PSCI here is served via HVC instead. The
+instruction was trapping into the kernel's own exception handler on every
+boot, not corrupting memory or racing anything, despite investigation
+initially suspecting both. Root-caused via live gdb single-stepping, which
+also surfaced and fixed a real debugging-environment gotcha along the way:
+`starkernel_kernel.elf` is not the binary that actually runs under
+`MONOLITHIC_BUILD` (`starkernel_loader.efi` is, a completely separately-linked
+artifact) — every earlier breakpoint attempt had been aimed at the wrong
+file. Fixed: `smc #0` → `hvc #0`. First clean aarch64 `BYE` exit recorded.
+
+Also fixed, found incidentally during the aarch64 investigation: PSCI
+`SYSTEM_RESET`'s function ID used the SMC64 calling convention (`0xC4000009`),
+which isn't a real PSCI function ID (`SYSTEM_RESET` has no SMC64 variant) —
+corrected to the valid SMC32 encoding (`0x84000009`).
+
+Full three-arch DoE campaign (`L8-DOE`, 48 trials each) re-run clean on all
+three architectures post-fix: stress campaigns 30/30 PASS, clean `BYE` exit,
+no exceptions. Full investigation trail, evidence, and dead ends in
+`FABRIC-2.md` Sections H and I.
 
 ## 2026-07-24 — Kernel 3-arch acceptance test re-run; amd64 dict_hash non-determinism root-caused (`lithosananke`)