fix(picker): identify worktree rows by path, not branch name

[max-sixty]

The interactive picker's alt-r removal signal carried each row's branch name. Detached worktrees all report (detached), so two detached rows produced the same signal — the collector matched by branch, fell back to the first detached worktree in git worktree list, and could prepare removal for the wrong one. The items.retain call also dropped every row sharing that text.

Worktree-backed rows now return a unique worktree-path:<path> token from output(); PickerRemovalTarget::from_signal decodes it back into an exact RemoveTarget::Path / Branch, replacing the branch-match-then-first-detached fallback. A picker_item_identifier helper resolves the switch identifier off the same token (the switch path can no longer read it raw, since output() now returns the token for every worktree row).

Includes a regression test — two detached worktrees, alt-r on the second removes exactly that one — verified to fail without the fix.

This was written by Claude Code on behalf of Maximilian Roos

[worktrunk-bot]

codecov/patch failed — 7 added lines uncovered, all in src/commands/picker/mod.rs (94.53%):

• L159, L163 — early-return guards in PickerRemovalTarget::from_signal (empty trimmed signal; worktree-path: prefix with empty path after the strip).
• L182, L187-L190 — the fallback path in picker_item_identifier (when as_any().downcast_ref::<WorktreeSkimItem>() returns None).

The from_signal guards are trivially testable with a small unit test:

#[test]
fn test_picker_removal_target_from_signal_rejects_empty() {
    assert!(PickerRemovalTarget::from_signal("").is_none());
    assert!(PickerRemovalTarget::from_signal("   ").is_none());
    assert!(PickerRemovalTarget::from_signal("worktree-path:").is_none());
}

The picker_item_identifier fallback is harder — it's only reachable when downcast_ref fails (the skim 0.20 cross-thread TypeId bug noted in the inline comment). One option is a test that passes HeaderSkimItem (which downcast won't match), exercising L182 and L187-L190 minus the WorktreePath arm. Another option is to drop the fallback if the maintainer is confident picker_item_identifier's callsite always runs on the main thread where the downcast succeeds — the original code's detached-worktree special case relied on the same downcast working there.

Happy to push a commit with the from_signal test plus either a HeaderSkimItem test for the fallback or a fallback removal, whichever you prefer. Dismissing the approval per CLAUDE.md's codecov/patch gate.

codecov/patch failed — 7 uncovered lines in picker/mod.rs

[worktrunk-bot]

codecov/patch failed again — 5 of 28 added lines uncovered on this commit (82.14%), all in the new test code:

• L1027, L1033 — the _ => panic!(...) arms of the two match blocks in test_picker_removal_target_from_signal. They're unreachable when the Some(...) arm matches.
• L1045-L1047 — FakeSkimItem::text(). SkimItem requires text(), but the test path only exercises output(), so the body never runs.

Both gaps are mechanical to close: replace the two match/_ => panic! blocks with assert!(matches!(... if ...)), and call .text() once on the fake item alongside the existing picker_item_identifier assertion. Inline suggestions below. Happy to push the commit if you'd rather not hand-apply.

Dismissing my approval per CLAUDE.md's codecov/patch gate.

codecov/patch failed — 5 uncovered lines in the new test code; analysis in follow-up review