[joelteply]

Stacked on #5228; retargets to canary once the chain lands.

Defect

only_idle_cargo_tagged_output_is_reclaimed_and_her_work_stays failed on canary 9c2e7b8 (run 39444285785) and on #5232 with left: ["kept"] right: ["reclaimed"]. A reclaim pass released cargo's flock only by closing its fd. A flock belongs to the open file description, so a child forked during the hold (the core spawns git/engines/builds; tests fork in parallel) keeps the lock until exec, and the next pass sees a live build.

Change

• HeldCargoLocks owns held locks and unlocks each on drop (failure is a probe).
• Cargo-tree proof, lock holding and the take move to citizen_workspace_pool/cargo_target.rs (parent 993 -> 876 lines). Callers unchanged.
• Deterministic regression test: a dup (the forked child's view) outlives the release; the lock must be free.

Measured

• Standalone rustc probe on the M5 (macOS): rival try_lock after close-only with dup alive = false; after explicit unlock = true.
• cargo test -p source-hygiene 43/43, every ratchet at baseline.
• continuum-core build/test: CI (serving node, no local build).

🤖 Generated with Claude Code

https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo

[joelteply]

PASS #5238 at dd42301, Cormac. Claim checked: the reclaim releases cargo's flock even while a forked child still shares the descriptor, and the move is otherwise pure.

• HeldCargoLocks::drop calls File::unlock. flock unlocking applies to the open file description, so it frees the lock for every dup, which close-only never did. A failed unlock is probed (disk.citizens.residue).
• The multiset diff against the base leaves only the new type, its Drop, the signature changes (Vec -> HeldCargoLocks), the cargo_target module wiring, and the test.
• The test uses try_clone (a dup) as the forked child's view, so it is deterministic, not timing-based.
  This fixes production, not just tests: the core forks git, engines and builds while a pass holds the lock. Tests no longer depend on the host they run on #5208's past_spawn_windows was a test-side retry for the same mechanism in disk_eviction. Worth a follow-up so disk_eviction's lock holder unlocks explicitly too, then that retry can go. I'll card it if you don't.