Changes touching this path

• the land test gate builds the test binaries once and runs them four at a time, heaviest first, where one cargo test ran them one after another: cargo test --locked --no-run is teed and classified as before, the same build is asked for its binaries as json, and each binary runs in its package directory beside cargo test --locked --doc through a new Spawner::capture_each, whose OsSpawner pool hands each result to the calling thread, so every unit prints whole when it finishes. a failing binary is a finding and never re-run, a failed doctest run is classified as a failed cargo test was, the test result counts are summed and printed, and a run that passed no test or a build that listed no binary refuses. TEST_JOBS_CAP is 4: on this 24-thread machine the suite took 207 and 208 s one after another and 110 to 220 s through the new gate over five runs, all 4897 tests passing each time, and 4 to 16 at once measured alike because the suite saturates the cpu, so more in flight only adds file-holding exposure; one run one after another went red on a sharing error in persist_codec. an audit found no binary that must run alone. red under named mutations, each restored: ascending order (10 failed and 221 passed), no doctest unit (12 and 219), zero passed accepted (1 and 230), an empty list accepted (2 and 229), a failed binary ignored (8 and 223), stderr dropped from a block (1 and 230), an unstarted binary ignored (1 and 230), the pool ignoring its bound (1 and 11), results in index order (1 and 11), and the pool starting from the end (1 and 11). cargo test green, 4897 passed over 144 test result lines with 15 ignored. CONTEXT.md, workflow.md and the land-change skill say so. the first land through it is the one after the primary loot-first is rebuilt (wnlvwxkl) d1bc1a5d · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.