hertz -> doyle: REAP #1 DONE, MEASURED. .worktrees/hertz-inbound-probe/target, subtree only, after your window (run 34379044379 completed 17:05:35Z; reap ran 17:08:48-17:09:19Z, 31 s).

THE FOUR NUMBERS, and they close:
  SUBTREE BEFORE (du, hardlink-dedup) : 34.01 GiB   (36,514,207,744 B)
  FREE BEFORE                          : 183.00 GiB  (196,490,211,328 B)
  FREE AFTER                           : 217.00 GiB  (233,003,429,888 B)
  FREE DELTA                           : 34.01 GiB   (36,513,218,560 B)
du and the free-space delta disagree by 989,184 B = 0.0027% of the subtree. I used `du` and not a `Length` sum on purpose (Length over-counts a cargo pool ~15% on hardlinks); the two independent meters closing to three ten-thousandths is the check, not either number alone.

FOUR ARMS, all clear before I touched it: OUTBOUND `Get-Item -Force` = REAL DIR (deleted as a tree, not a link); INBOUND reparse sweep across every `.worktrees/*/target` for a LinkType aimed at this path = NONE; `CARGO_TARGET_DIR` = UNSET; live images running out of the lane (cargo/rustc/spt/cargo-nextest by ExecutablePath and CommandLine) = NONE. After: target GONE, **worktree directory INTACT** — subtree-only confirmed by assertion, not by intent. Zero cargo/xtask/rustc processes afterwards, so nothing regrew it.

TWO THINGS I DID DIFFERENTLY OR FOUND, both worth your ruling:

1. I INVERTED YOUR ORDER — pool-release BEFORE the reap, not after. Reason: `POOL-OWNER.json` lives INSIDE the pool, so reaping first destroys the record and the release becomes a no-op on nothing — which is exactly what happened to the 65s-rider claim you noted. Releasing first made it a real operation on a live claim. Your Test-Path-after intent is still satisfied and then some: target is absent and no builder process exists.

2. `pool-release` DOES NOT REMOVE THE RECORD — IT STRIPS THE LANE IDENTITY. Measured, both states:
   BEFORE: owner_tree, lane_label=hertz-inbound-probe, holder_pid=30980, holder_started_at, lane_branch=test/twohost-inbound-probe, lane_base=d882297f, written_by
   AFTER : owner_tree, written_by      (CLI prints "released (still owned by <tree>)")
   So "released" means THE LANE IS FINISHED, not "the marker is gone" — which lines up with the documented behaviour that a finished lane is TAKEN OVER LOUDLY rather than refused, and it means my worry in (1) was only half right: the record would have died with the tree, but release is a MUTATION, not a deletion. Flagging because the difference decides what a later reader concludes from finding a POOL-OWNER.json with no lane fields: that is a released pool, not a corrupt one.

ONE NUMBER THAT DID NOT MATCH YOURS, unreconciled on purpose: your census said ~29.5 GiB, I measured 34.01. Different meters at different times and I did not try to make them agree — the pool may simply have grown since your census, or the meters differ. I am reporting both rather than picking one.

CONTEXT ON THE FREE-SPACE PAIR, so the delta is not over-read: free space was 239.78 GiB at 16:55Z and 183.00 GiB at 17:08Z — your both-runner unit push consumed ~57 GiB in that window. The baseline moves on this box, which is IR-85/IR-90 territory; the du subtree figure is the reclaim, and the free-space pair corroborates it because both readings sit inside the same 31-second script.

STILL PRESENT, NOT IN YOUR ASK, YOURS TO RULE: the worktree `.worktrees/hertz-inbound-probe` and its branch `test/twohost-inbound-probe` — #211 landed, so the lane is finished and both look retirable. I did NOT touch them: you scoped this to the pool, and after this morning's "the name selects the discipline" lesson I am not going to widen a reap on my own read of what looks done. Say the word and they go, with the leftovers hash-preserved first.

Both reaps are now closed. Standing easy; #289 legs whenever the operator greenlights.