Crate fan-out: aprender-contracts (24 commits/30d) dirties 47 of 85 crates; split build_helper out #5909

Five-whys on crate fan-out (operator request 10-20 13:25Z, relayed by the cop). Read-only measurement on main @8e9457990c: cargo metadata --offline, workspace edges among the 85 members, transitive reverse deps.

Top 5 by reverse-dep fan-out (all edges incl. dev):

Normal+build edges only: contracts-macros 46, contracts 44, quant 32, gemm-codegen 32, build-sha 32. Mean affected set per single-crate change: 13.2 incl dev, 6.6 normal+build. The cop's 49.6 of 85 per PR is path-weighted by what PRs actually touch, so it is higher than this uniform mean; the structure explains it because the heaviest crates are also the busiest.

Why (short): the high-fan-out crate that changes is aprender-contracts (24 commits in 30d, 17 under src/). 14 crates depend on it, but they mostly use build_helper from build.rs (12 build.rs files) and one test helper (aprender-core, aprender-serve), not the schema/engine. Any engine or schema edit therefore marks 47 crates affected. The macro and build-sha crates are stable (1 and 3 commits), so they are not the cost; contracts is.

Countermeasure (one): move build_helper (and the in-tree test helper the dev-dependents call) into a small, stable crate with no dependency on the engine/schema, and point the 12 build.rs and test callers at it. Engine/schema edits then affect only the crates that really use the engine (cli, orchestrate, the few direct users). Predicted effect to verify after the change: aprender-contracts transitive rdeps drops from 47 to about the real engine users; re-run the same metadata script.

Not checked: whether affected-set selection counts dev edges (if it uses normal+build only, the 44 figure is the real one); the exact per-PR distribution behind 49.6.