Fix aarch64 Stadium/COOL O(ncells) scan; rerun std79 DoE clean, 81/81 (FABRIC-3.md §XVI)

Root cause of the 90+ minute aarch64 VM-birth stall found in §XV: stadium_admit()'s
eviction-fallback scan iterated the entire stadium_ncells array filtered by owner,
not the calling VM's own resident cells as its own doc comment claimed. Combined
with stadium_grant_quota() always splitting from Hera's shrinking free list and
stadium_word_dispatch() calling stadium_admit() per distinct word a VM's capsule
executes, this compounded into a real O(n) blowup — catastrophic specifically on
aarch64 because its -m 4096 (vs 1024 on amd64/riscv64) inflates the kmalloc heap
kmalloc_init() bisects down to, which inflates stadium_ncells 4x (335,544 vs 83,886
cells, measured from boot logs).

Fixed by threading a real per-VM doubly-linked resident-cell list
(StadiumVMQuota.resident_head + stadium_resident_next[]/stadium_resident_prev[])
so the fallback scan is bounded by that VM's own resident count, not the global
cell array size.

Verified with a full rerun of the 3x9x3 std79 DoE campaign from scratch: one
continuous boot per architecture, all 9 identities simultaneously live throughout
(the 3-boot aarch64/riscv64 batching workaround is no longer needed). 81/81 trials
correct, 0 mismatches, DOE-RUN header sequence md5-identical across all three raw
logs. Identity 04's attach on aarch64, which stalled 90+ minutes before, now
completes in ~34s; full boot-to-DoE-complete in ~290s.

Corrects an earlier misreading (carried into §XV, std79-doe.fth's comments, and
the project memory note) that described the symptom as a runaway "335,000+ cycles"
dispatch counter — those were cell array indices, not an event count.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo

experiments/std79-doe/std79-doe.fth

@@ -123,21 +123,24 @@ VARIABLE SW-I  VARIABLE SW-J  VARIABLE SW-VI  VARIABLE SW-VJ
 VARIABLE CURR-ID
 VARIABLE CURR-REP
 
-( Boot-batching support, added 2026-09-11 (FABRIC-3.md SXV): aarch64 hit a )
-( severe, apparently superlinear per-tick slowdown once ~9-10 VMs stayed )
-( simultaneously live at once (Stadium COOL dispatch cell counters running )
-( into the hundreds of thousands with zero forward progress for 90+ )
-( minutes) -- not yet root-caused, flagged as a real defect worth chasing )
-( separately. Worked around by running each architecture as 3 boots of 3 )
-( identities each (zuse+rajames+00, 01+02+03, 04+05+06), every boot sharing )
-( the SAME seed so INIT-MATRIX/SHUFFLE-MATRIX produce the identical master )
-( 27-slot permutation every time -- only ACTIVE-LO/ACTIVE-HI differ, so )
-( each boot walks the FULL master order and simply skips any slot whose )
-( identity isn't in its own live subset. The recorded run_id is always I )
-( itself (the slot's true position in the master shuffle), never a )
-( separately-incremented counter, so row order stays meaningful and )
-( comparable across all 3 boots -- classic DoE "blocking": randomized )
-( within, blocked across, by a practical constraint. )
+( Boot-batching support, added 2026-09-11 (FABRIC-3.md SXV). Originally a )
+( workaround for a real aarch64 Stadium/COOL scaling bug -- root-caused and )
+( fixed 2026-09-11/12 (FABRIC-3.md SXVI, src/starkernel/vm/stadium.c): )
+( stadium_grant_quota() halves the granting VM's own free list on every )
+( birth with no floor, and stadium_admit()'s eviction fallback used to scan )
+( the ENTIRE global cell array (stadium_ncells, in the hundreds of )
+( thousands on aarch64's larger RAM-scaled Stadium) filtered by owner, )
+( instead of walking just the calling VM's own resident cells as its own )
+( doc comment already claimed -- fixed by threading a real per-VM resident )
+( list. A single boot with all 9 identities simultaneously live now works )
+( cleanly on all three architectures (see results-20260911-stadium-fix/), )
+( so ACTIVE-LO/ACTIVE-HI is no longer load-bearing -- kept only as general )
+( flexibility: every boot shares the SAME seed so INIT-MATRIX/SHUFFLE-MATRIX )
+( produce the identical master 27-slot permutation regardless of how many )
+( boots this runs across; only the ACTIVE-LO/ACTIVE-HI filter differs if )
+( split. The recorded run_id is always I itself (the slot's true position )
+( in the master shuffle), never a separately-incremented counter, so row )
+( order stays meaningful and comparable across any number of boots. )
 VARIABLE ACTIVE-LO
 VARIABLE ACTIVE-HI
 : ACTIVE? ( idx -- flag )