Brummel
483117d39b
bugfix-swarm-rc-alloc-undercount, RED stage (audit trail; GREEN follows separately via implement mini-mode). Root cause of the m5.2-resume-attempt residual (the M5 swarm leak-proof still non-deterministic after the atomic-counter fix7bfa11e): ail-embed/build.rs declares cargo:rerun-if-changed only for the kernel .ail + build.rs itself — NOT runtime/rc.c. So Cargo never re-ran build.rs after 7bfa11e; the swarm keeps linking a stale pre-7bfa11e libailang_rt.a whose g_rc_*count++ is the old non-atomic racing increment.7bfa11ewas correct and is unchanged; it just never reached the ail-embed binary. This explains why the isolated crates/ail RED (rebuilds the staticlib fresh per run) is green while the ail-embed swarm is not, and the frees-stable/allocs-jitter asymmetry (few TLS-NULL frees = no contention; millions of TLS-NULL host allocs = race on the stale non-atomic counter). Framing: a genuine defect (build-dependency completeness gap), NOT test-methodology unsoundness — with a fresh archive the swarm Σ-over-stat-lines balances deterministically (Σallocs==Σfrees== 12000003, 5/5 per the debugger). runtime/rc.c at HEAD is correct; the GREEN fix is in the build script, not the runtime. RED pins the CAUSE deterministically (the symptom is non-deterministic by construction): objdump the libailang_rt.a that build.rs emitted for this crate; assert >=2 lock-prefixed instructions (the atomic lock incq for g_rc_alloc_count + g_rc_free_count from current rc.c) and that it matches a freshly-built archive. Boss-verified RED: linked archive has 0 lock insns ("STALE pre-7bfa11e archive linked"). Does NOT touch the committed #[ignore] of symbol_fan_swarm_leak_free nor the isolated embed_rc_global_stats_race RED (both correct, unchanged).