Worktree picker lists prunable worktrees, and selecting one raises a raw error dialog

The problem

When a linked worktree's directory is deleted outside Desktop with a plain rm -rf, git keeps the worktree's admin metadata under <main>/.git/worktrees/<name> and reports the entry as prunable:

$ git worktree list
/path/main-repo  9bc5f36 [main]
/path/wt-rm      681b19b [wt-rm] prunable

Desktop's worktree picker keeps showing that entry under Linked Worktrees indefinitely, even though the directory is gone. It appears the list reflects .git/worktrees/ without filtering entries git flags as prunable.

This isn't stale UI state: the entry persists after removing the repository from Desktop and adding it again, and across a full quit and relaunch. It disappears only once something runs git worktree prune.

Selecting the stale entry is a guaranteed dead end. Desktop shows a raw error dialog:

The worktree path '/Users/…/wt-rm' does not appear to be a valid Git repository.

That's the throw in _switchToWorktree surfacing directly to the user — getRepositoryType returns missing for the deleted path, the kind !== 'regular' && kind !== 'unsafe' check fails, and the exception is presented untranslated with no recovery action beyond Close. The entry then stays in the list, so the same dead end is reachable again.

The contrast within a single session makes the inconsistency clear — a worktree deleted with git worktree remove (which also drops the metadata) vanishes from the picker correctly, while one deleted with rm -rf lingers and is still clickable.

Release version

3.6.3

Operating system

macOS 15 (Darwin 25.5.0)

Steps to reproduce the behavior

mkdir ghd-worktree-repro && cd ghd-worktree-repro
git init -b main main-repo
cd main-repo
git commit -qm "Initial commit" --allow-empty
git worktree add -b wt-rm ../wt-rm

1. Add main-repo in Desktop and open the worktree picker — wt-rm is listed.
2. In a terminal: rm -rf ../wt-rm (note: no git worktree remove, no prune).
3. Reopen the picker.
4. Click wt-rm.

Expected: wt-rm is no longer offered, since its directory doesn't exist.

Actual: wt-rm is still listed under Linked Worktrees, and stays listed after removing the repository from Desktop and adding it back, and after quitting and relaunching Desktop. Clicking it raises the error dialog above, and the entry remains in the list afterwards.

Suggested fix

Filter out entries reported as prunable when building the picker list. git worktree list --porcelain emits a prunable line for these, so the information is already present in the output Desktop parses in parseWorktreePorcelainOutput.

Failing that, _switchToWorktree shouldn't surface a bare exception for a case that's reachable by an ordinary click — but not offering the entry at all seems better than handling the error.

Additional context

Found while investigating a separate worktree-fallback bug: #22604, filed on its own as it's an unrelated code path.

Distinct from #22335: that covers deletions performed through Desktop failing to refresh the list. This entry is refreshed correctly and still listed, because the underlying git metadata really is still there.