refactor(remove): report a removal's branch fate, not its plan's intent

[max-sixty]

Follow-up to #3633, which patched the most visible symptom (prune's summary counting candidate kinds). This lands the structural fix behind that class: the removal chain returned nothing from execution, so everything downstream reported the plan's intent as if it were the outcome. The type even said so — RemoveResult was produced by prepare_worktree_removal before anything ran, and the codebase couldn't agree on what it was (RemovePlans in remove.rs, plan in prune, result in the handler).

The plan/outcome split

RemoveResult → RemovalPlan (variant RemovedWorktree → Worktree), and handle_remove_output now returns a BranchFate: Deleted / Retained / NotAttempted observed synchronously, Deferred only for the detached legacy fallback whose outcome this process never sees. Consumers report the fate:

• wt remove --format=json said "branch_deleted": true while stderr said ▲ Removed worktree but kept branch feature (not integrated) — a pre-remove hook had advanced the branch, the SafeDelete re-check declined, and stdout reported the plan anyway. Now false.
• wt step prune's summary counts executed outcomes, so a deletion declined mid-run reads ✓ Pruned 1 worktree, matching the per-item line above it. A declined orphan deletion (no worktree entry, nothing removed at all) now drops out of the removed list entirely instead of being counted as either lie.
• The detached fallback emits the "kept branch" correction in the one case it can know (no CAS tail to append), instead of letting the progress message's "worktree & branch" stand uncorrected.

The picker's foreground: true, silent: true contradiction collapses into one RemovalExecution::{Foreground, Background(fallback), Silent} axis, and the four hand-rolled capture-refs-then-CAS-delete sites share one worktrunk::git::execute_branch_deletion — the single spelling of "the plan said delete; do it now, against fresh refs".

For the reviewer

src/output/handlers.rs carries the bulk: each execution path constructs its fate where it observes the result, and rendering decisions (foreground propagates deletion errors, background warns, silent does neither) are unchanged. The merge with #3631's concurrent prune rework is the diff's riskiest region — the worker result channel widened from Result<bool> to Result<Option<bool>> so fates flow back through the done-channel and the collector stamps candidate.deletes_branch before the summary and JSON read it. Deliberately not done: reusing the planner from wt merge's finish path (its divergences — clean-check strictness, preserve-vs-error on primary, merge-target — are intentional), and threading the fallback mode structurally (it just relocates an unreachable arm).

Zero snapshot churn: the change is provably invisible wherever intent matched outcome. The divergence cases are pinned end-to-end by tests whose hook must be the branch tip to pass. The one deterministically unreachable arm is the detached-fallback warning (needs a cross-filesystem rename failure); expect codecov/patch to flag those few lines.

This was written by Claude Code on behalf of max

[worktrunk-bot]

Reviewed the full diff and traced the plan/outcome split end-to-end — no correctness issues found. Notes for the record:

• The four hand-rolled capture-refs-then-CAS sites collapse into execute_branch_deletion equivalently; the .and_then→? swap preserves the "capture failure ⇒ Err, never a lost commit" contract. The one behavior nudge is the picker's do_removal, where a capture_refs() failure now routes into the row's error arm instead of being silently skipped — a strict improvement.
• The reporting change is the substance: to_json/prune summary now read BranchFate (observed) rather than deletes_branch() (intent). Deferred.deleted() == true keeps the pre-existing detached-fallback behavior (intent, since the outcome is unobservable), so no regression there; the SafeDelete-no-tail arm correctly flips to Retained. The multi-remove .zip(fates) aligns because the fate Vec is pushed in the same others→branch-only→current order the JSON chains.
• Divergence cases are pinned by the two new tests whose hook must land as the branch tip to pass — good coverage for exactly the intent≠outcome path this PR exists to fix.

Holding the merge decision for a human rather than auto-approving: this lands on worktrunk's data-loss surface — src/output/handlers.rs (std::fs::remove_dir_all, git branch -D, git worktree remove) and src/git/remove.rs (the removal engine, new execute_branch_deletion). Per the repo's review policy that surface isn't an agent's to sign off on, even when the change reads as reporting-only. The behavior of the actual deletions looks unchanged to me, but a human should confirm before merge.