[Bug]: project setup-delete leaves the primary workspace row under an "Unknown" heading with no remove path (UI or CLI)

### Operating system

Windows 11 Pro (local runtime)

### Orca version

1.4.200 (desktop + CLI, same machine)

### Details

**Short summary:** `orca project setup-delete --setup ` removes the project/setup record but leaves the repo's primary checkout row in the sidebar under an **"Unknown"** heading. That row has no hover actions and no context menu, `orca worktree show/rm` cannot address it (`selector_not_found` for `path:`, `id:::` and `identity:` forms), and `orca repo add` on the same folder mints a new UUID (as in #14316) instead of reclaiming the row. Result: permanent ghost rows that neither the UI nor the CLI can remove.

#### Steps to reproduce

1. Register a plain local git repo: `orca repo add --path C:/Users//Projects/get-trashed` → sidebar shows project `get-trashed` with its primary workspace `main`.
2. Remove it via CLI: `orca project setups` (take the setup id) → `orca project setup-delete --setup --json` → `ok: true`.
3. Look at the sidebar.

#### Expected

The project heading **and** its workspace rows disappear (the docs say deleted projects leave "no permanent ghost rows").

#### Actual

- `project setups` / `repo list` / `worktree list` no longer contain the repo.
- The sidebar still shows a heading `Unknown` with the old primary workspace row (`main · primary`) beneath it. Reproduced twice in a row (two hobby repos deleted the same way → two `Unknown` headings).
- Hovering the row shows none of the usual buttons (no "Project actions", no "Workspace options"); there is no context menu, so the user cannot remove it.
- The accessibility tree exposes the row as `worktree-list-option-repo::local|::C:/Users//Projects/get-trashed`, i.e. it still references the deleted repo id.
- `orca worktree show --worktree path:C:/Users//Projects/get-trashed` → `selector_not_found`; same for `id:::` and `identity:wt2:local:`.
- `orca repo add --path ` creates a **new** setup id; the `Unknown` row stays (now next to the re-added project), so re-registration is not a workaround.

#### Notes

- No live terminals were involved (the rows had `live:0` before deletion), so this is the static-row variant of #14316: that issue is about live terminals being orphaned on re-registration; this one is about the deletion path alone leaving an unremovable row.
- Deleting via the UI's **Remove Project** was not tried before the CLI route; if the UI path cleans up correctly, the CLI path should do the same.
- Happy to provide `orca diagnostics` output or the DB rows if you tell me where the sidebar workspace records live.

Reproduce the issue with `orca repo add`, `orca project setups`, and `orca project setup-delete --setup --json`, then inspect the sidebar row exposed as `worktree-list-option-repo`. Trace the setup deletion path and the sidebar workspace records; done means the deleted project heading and primary workspace rows disappear, while `repo list` and `worktree list` remain consistent.

Written by the indexing model from the issue text.