Host-blind lookups remain in multi-host repo/project setup state

Follow-up from the review of [#6030]()/[#6031]() (tracking issue stablyai/orca#6032, core fixed by stablyai/orca#6136). Four narrow host-blind lookups remain on current main:

1. `projectHostSetup` **update/delete route by bare setup id** — `src/renderer/src/store/slices/repos.ts:2539, 2587` resolve mutation targets by `setup.id` alone, and legacy projected setups use `id: repo.id`, so same-id setups across hosts can target the wrong host (state maps also replace/filter by bare id). Fix note: client and server host *perspectives* differ (`runtime:` vs `local`), so the fix must resolve within each side's own perspective — do not forward client host ids over RPC.
2. **SSH remote-workspace snapshot scoping matches by repoId only** — `src/renderer/src/hooks/useIpcEvents.ts:442-459` (also disconnect PTY-clear ~2713-2720 and reconnect spawn-retry ~2740-2744); a repo id spanning an SSH row and another host's row lets remote snapshots claim foreign worktrees' tabs.
3. `ensureRuntimeEventRepoKnown` **is host-blind** — `useIpcEvents.ts:972`; a runtime `worktreesChanged` for a repo id already known on a different host skips the env repo fetch and the follow-up refresh resolves to the wrong/focused host (staleness only).
4. `resolveWorkspaceCreationTarget` **setup lookup by bare id** — `src/renderer/src/lib/project-host-workspace-target.ts:126`, while the sibling branches of the same function host-qualify.

Plan: one renderer-only PR with host-qualification guards + regression tests for 2–4, and a separate contract-aware PR for 1.

Credit: this class was identified by @prateek's [#6030]()/[#6031]() stack and confirmed during its supersession review.