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 `/.git/worktrees/` 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

```bash
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.