CI scope: perry-runtime changes never run perry-stdlib's lib tests per-PR (_is_fanout_leaf excludes it) — #11417 landed red unnoticed #11423

Gate hole: per-PR CI never runs the perry-stdlib lib tests for a change that touches only perry-runtime.

test.yml's pr tier runs cargo test --lib --bins -p perry-stdlib only when perry-stdlib itself is in scope. scripts/ci_test_scope.py's _is_fanout_leaf deliberately leaves perry-stdlib out of the reverse-dependency fan-out, on the premise that its tests "do not exercise perry-runtime internals".

They do. #11417 was the result: the perry-stdlib lib suite was red on clean main, failing every run on macOS, including single-threaded. The causes were perry-runtime bugs, fixed in #11422: dead-thread closure side-table entries surviving Arena::drop, and js_loop_turn_bounded skipping its turn on a stale NOTIFIED flag. Also turnloop (#10354) changes that broke stdlib crypto tests. For example, a change to crates/perry-runtime/src/arena/block.rs scopes to perry and perry-runtime but not perry-stdlib. So the breakage lands on main, is caught only by nightly or full runs (Linux, default threads), and the next PR that touches perry-stdlib inherits the red, as a failure it didn't cause.

Ask. Include perry-stdlib in the fan-out for perry-runtime changes, or at least for the runtime subsystems its tests drive: gc/, arena/, closure/, event loop/turnloop, promise/async bridge. Or state explicitly why the cost isn't worth it. Per the gate-health rules in CLAUDE.md, a suite that exists but can't go red for the changes that break it is case 4: the gate runs, but its subject never did.