docs: core stabilization audit — why core grows per-feature, and the A1-A7 program (#49)

A 12-agent audit of why every new feature requires a core change. Finds that
core has a declarative OUTBOUND path (Engine.call over gamedata) but no
declarative INBOUND path: every engine->JS notification is a hand-rolled
vertical slice, and the JS half of the API is compiled into the Rust.

Quantified: v8host.rs 6,550 -> 19,028 lines in 24 days (1,805 of them JS in a
Rust string); a new hook costs 7-9 coordinated core edit sites (traced against
625878b); ~60% of feature-slice core growth is a copy of an existing pattern.
Existence proof that it is fixable: movement-control (5ff62b4 + 6fe8647)
shipped 14 writable fields with zero core/src lines.

Proposes A1-A7 + B1-B4 but commits to nothing; each becomes its own slice spec
when picked up. Section 4(d) records ten things that look like bloat and are
load-bearing, with reasons, so they do not get re-proposed.

Records its own trust caveats: the adversarial stage returned 'survives' on all
22 findings and did not do its job (the synthesis pass did the killing), and
line numbers are as of ~20 commits behind origin/main with the A1-A3 citations
re-verified against 517b71b.