Archived worktree threads don't reliably delete their local branch — worktree directories get recycled across threads, breaking the archive→branch-delete link

Summary

Manually archiving a worktree thread is supposed to remove both the worktree
and its local branch. In practice the branch is frequently left behind, even
though the user archives almost every thread once its work is done.

Root cause (reproduced via git reflog inspection)

Worktree directories are not one-per-thread — they get recycled as scratch
space across many threads/branches over their lifetime via plain git
checkout inside the same folder, rather than a fresh git worktree add per
thread.

Example from a live repo: the worktree directory prune-merged-branches-d580c3
hosted 9 different branches in under 48 hours (per git reflog show HEAD):

claude/prune-merged-branches-d580c3 (the thread the folder was named for)
→ claude/modest-hypatia-17a87a
→ claude/pin-screen-test-clock
→ claude/review-pr-27-222c30 / review-pr-29-29366f (ad-hoc PR-review checkouts)
→ claude/test-seed-cache-mutation-809c41
→ claude/ripplestar-feature-suggestions-476dee (currently checked out)

Every earlier branch in that chain is still sitting in git branch as an
orphan — merged into main, no worktree pointing at it, never deleted.
Checking other active worktrees in the same repo showed the same pattern
(19–37 branch switches each via reflog).

Hypothesis for the bug

The archive action appears to determine "which branch to delete" from
whatever is currently checked out in that worktree path at the moment of
archiving, rather than from the specific branch the thread was originally
created for. Once a worktree folder gets reused for a different thread (or a
quick ad-hoc git checkout for something like a PR review), the original
thread's branch is no longer discoverable from that path — so archiving it
later has nothing to delete, and the branch orphans permanently.

Impact

Local branches accumulate indefinitely (41 local branches vs. 7 active
worktrees observed in one repo after ~2 days of normal use), even though the
user is following the intended workflow of archiving every finished thread.

Suggested fix direction

Track the branch a thread owns independently of the worktree path's current
checkout (e.g. record it at worktree-creation time), so archive-time branch
deletion targets the right ref even if the worktree folder was reused for
other work in between. Alternatively, stop recycling worktree folders across
unrelated threads.