fix: closing one worktree closes every repo's same-numbered worktree

[SmolSmolStar]

Summary

In a mixed-repo workspace, closing a single worktree's terminal (the close-process × button) can close every other repo's worktree that shares the same number. Reproduced in the wild: clicking close on sandbox/work1 also closed agent-workspace/work1, USDUC/work1, and Cat-Code-Academy/work1, leaving only Test-game/work4 (the one worktree on a different number).

Root cause

SessionManager.getSessionGroupIds builds its close-list from two keys:

const keys = [composedKey, parsedWorktreeId].filter(Boolean);

composedKey is repo-scoped (sandbox-work1, correct), but parsedWorktreeId is the bare worktree number (work1). parseWorktreeKey only treats <repo>-work<N> as repo-scoped, so a bare work1 lookup in getSessionIdsForWorktree matches every repo's work1 in the workspace.

The existing tests only covered cross-workspace scoping (already handled by the workspace filter), so this same-workspace / different-repo collision slipped through. It's the same class of hazard the repo's own docs call out for remove-worktree (bare worktree ids nuke all repos).

Fix

Only ever key on repo-scoped identifiers:

• the composed ${repositoryName}-${worktreeId} key, and
• the session id's own repo-scoped prefix (e.g. sandbox-work1).

Never the bare worktree number.

Test plan

• Adds a regression test that seeds several repos sharing work1 (plus one work4) in a single workspace and asserts getSessionGroupIds('sandbox-work1-claude') returns only sandbox's own sessions.
• Verified the test fails on the old code (returns 4 extra sessions) and passes with the fix.
• Full sessionManager.closeSession suite green (9/9), node --check clean.

🤖 Generated with Claude Code