fix(prune, remove, ci): count what a removal took, not what it selected

[max-sixty]

Three follow-ups from the review of #3533, which landed shared-branch retention across the removal surface. Each is small and independent; they share a branch because they came out of the same pass.

wt step prune counted kinds, not outcomes

A candidate's kind is what the scan selected, not what the removal took. A branch a sibling worktree still has checked out is retained, so a worktree candidate can take the worktree and leave the branch standing. The summary counted the kind anyway:

○ Worktree directory missing for feature; pruned
↳ branch checked out at ~/code/repo.feature
✓ Pruned 1 branch          ← the branch is right there

prune_summary now counts the planned outcome, so that reads ✓ Pruned 1 worktree — the stale entry, which is all that went. Both --format=json payloads gained branch_deleted for the same reason: a consumer reading {"branch": "feature", "kind": "branch_only"} would reasonably conclude the branch is gone.

The predicate has one home now. RemoveResult::to_json already computed branch_deleted inline; it moved to RemoveResult::deletes_branch() and both callers share it. That incidentally fixes a detached worktree reporting "branch_deleted": true beside a null branch — it has no branch to delete.

wt step prune --dry-run had the same defect and no per-item line to contradict it, so it now predicts retention too. A Prunable item has no plan until try_remove prunes its stale entry, so the dry run asks live_sibling_checkout — the same predicate the plan would.

RemoveTarget::Branch now means "a branch with no worktree"

All three callers resolve first and pass Path for anything with a worktree, so the arm handling "the branch turned out to have a worktree" was unreachable at selection time — codecov confirmed it never executed. Deleting it would have been enough, but the arm was a live hazard rather than dead weight: the picker builds a fresh Repository and re-lists worktrees between selecting a row and removing it, so a wt switch in another terminal can give a branch-only row a worktree mid-flight. The old code would then have removed that worktree, from a row that said "delete this branch" — the same defect class #3533 fixed.

✗ Branch feature gained a worktree @ ~/code/repo.feature since it was selected;
  to remove that worktree, run wt remove ~/code/repo.feature

test_prepare_removal_refuses_branch_that_gained_a_worktree covers the picker path. I checked it fails when the guard is neutralized rather than passing trivially.

affected tests (windows, advisory) was permanently red

git calls a file binary only when it finds a NUL byte in the first 8000, and two of the committed loose objects under tests/fixtures/*/_git/ are zlib streams small enough to have none. Those diff as text, so git diff writes raw deflate into its output, and cargo affected aborts decoding it as a string before running a test.

Reproduced with git show <commit> -- <object> (invalid UTF-8, byte 0x95 at position 5403) and confirmed fixed — the same command now reports Binary files … differ. The rest of _git/ stays text worth reading.

Testing

prune_summary_counts_a_retained_branch_as_worktree_only covers the counting; test_prune_retains_branch_checked_out_in_another_worktree gained an assertion on the summary line, and I verified it fails when the guard is removed. The six .snap changes are all the same added branch_deleted key.

This was written by Claude Code on behalf of max

[worktrunk-bot]

Reviewed the removal-surface logic closely (RemoveTarget::Branch in src/commands/repository_ext.rs, the prune counting in src/commands/step/prune.rs, RemoveResult in src/commands/worktree/types.rs). Per the repo's data-loss-surface policy I don't auto-approve changes to the deletion path — the merge is yours — but flagging that I traced it independently and found nothing to fix:

• RemoveTarget::Branch race guard is sound. wt remove resolves via resolve_worktree → worktree_for_branch, which returns Some for a stale (directory-gone) entry too, so any branch with an entry routes through RemoveTarget::Path; only a genuinely entry-less branch reaches the Branch arm. The deleted !wt.path.exists() prune-and-continue branch was therefore unreachable, and a worktree materializing in the resolve→prepare window is exactly the live race the new bail! refuses. test_prepare_removal_refuses_branch_that_gained_a_worktree covers it.
• Dry-run vs. actual parity holds. The Prunable predicate wt.branch.is_some() && live_sibling_checkout(...).is_none() matches what prepare_worktree_removal computes on the live path — live_sibling_checkout requires wt.path.exists(), so the stale entry itself is correctly excluded and a retained branch reads "1 worktree", consistent with the per-item retention line.
• deletes_branch() gate is correct. Adding branch_name.is_some() for RemovedWorktree fixes the detached-worktree "branch_deleted": true beside a null branch, and both JSON callers now share one predicate.

The .gitattributes fix is right too — a small enough loose object has no NUL in the first 8000 bytes, so git diffs it as text and emits raw deflate; marking _git/objects/** and _git/index binary keeps cargo affected from aborting on it.

Nothing actionable — leaving the merge call to you as the removal-surface owner.