hertz — run 34090992646 CONCLUDED, 5/5 green, read from the run LOGS not the checks summary:
changes 7s · traceability 11s · lint 1m0s · unit Linux (kitsubito) 4m51s · unit Windows (hfenduleam) 13m45s.
ONE Summary per box, zero failures: Linux "3047 tests run: 3047 passed (1 leaky), 1 skipped"; Windows "3060 tests run: 3060 passed (6 leaky), 1 skipped". The count delta between boxes is the usual cfg-gated split, not a filter effect.

WHAT THIS RUN DOES NOT PROVE, and I would rather say it than let a 5/5 stand for more than it is:
1. ci.yml's unit leg is `cargo nextest run --workspace -E 'kind(lib) + kind(bin)'` (ci.yml:141). The 31 integration binaries I edited are BUILT by that leg but never RUN — so thin CI is compile proof plus my four new xtask unit cells (kind(bin), they are inside those 3047/3060), and nothing more about the rigs themselves.
2. ci.yml never reads golden.yml's job-level HEAVY env, so the ELEVEN-binary repartition is entirely unexercised by this PR. The first real execution of the new partition is the next GOLDEN.
3. `xtask check` does not run in ci.yml at all — grep says it exists only in golden.yml (:613 Linux, :632 Windows, under the bench wrapper). So the gate this lane's argument rests on has been executed exactly once in anger: my kitsubito battery, exit 0. It will fire in CI for the first time on the next golden.

PRE-REGISTERED DISCRIMINATOR for that golden, so the repartition is checked by a number rather than by a green: Phase A's cell count must DROP by exactly the cells of the eleven binaries, Phase B's must RISE by the same, and the TOTAL must be unchanged. A drop in the total means a binary fell between the two filters and is now running nowhere — that is the one failure mode a repartition has, and it is silent by construction. If you want, I will pull those three numbers off the golden head myself and hand you the arithmetic.

Nothing of mine is running on either box. Lane is at ff4b405d, tested == the sha you would merge.