five-whys on crate fan-out: which core crates pull in most of the workspace #5795

Five-whys on crate fan-out: which crates pull in most of the workspace, and why.

Evidence (as measured by the test-affected script owner, relayed 2026-10-20 ~13:12Z): mean 49.6 of 85 workspace crates are affected per commit on main; 10 of 30 sampled commits affect ALL crates.

Cross-check, transitive reverse-dependency closure (cargo metadata --no-deps at main d1861e795e, normal+dev+build edges among the 85 workspace packages; regen script lives in the triage scratch, ledger.sh):

Direct fan-in is much smaller (aprender-build-sha 27, aprender-core 15, aprender-contracts 14), so the closure, not the direct edge, is what inflates it.

To answer (the five whys): why does a change to a leaf-ish crate such as aprender-build-sha or aprender-contracts-macros reach ~55 of 85 crates; which edges are dev-dependencies only (and could be cut or made feature-gated); which crates are depended on for one constant or one macro; what does a root Cargo.toml/Cargo.lock change do (affects ALL by definition).

Deliverable: a ranked edge list (which single edge removals cut the most affected crates), no behaviour change. Analysis only; no gate edits.