feat(remote): SSH remote workspaces — develop on Linux servers over SSH

## Request

Community ask (chat, 2026-09-13, Bevis):

> I have many projects that require SSH remote connections to Linux servers for development. Does the desktop version support connecting to remote workspaces?

Founder direction: SSH should become a fundamental, not a workaround.

## Current state (verified on main @ 3b00c1a15)

No. There is no SSH transport and no remote-workspace concept:

- No SSH crate anywhere in the 706-package locked graph (`ssh`/`ssh2`/`libssh`/`openssh`/`russh` all absent from every `Cargo.toml` and `Cargo.lock`); the `ssh` string hits in `crates/*/src` are incidental (shell tooling, tests).
- No `remote-workspace` surface in `crates/`, `docs/`, or `web/`.

Adjacent but different, so nobody mistakes them for this:

- `crates/tui/src/remote_control.rs` is account-owned remote control of the active **local** session — its own module doc says it is "deliberately a typed relay, not a remote shell".
- Fleet / cloud dispatch runs turns on runners; that is dispatch, not an interactive remote workspace.
- `docs/rfcs/REMOTE_SETUP_DESIGN.md` is Tailscale-first access **to** a local runtime from another surface; SSH appears there only as ad-hoc port-forward validation (`ssh -L 7878:127.0.0.1:7878`).
- Closed spikes: #1989 (tunnel eval), #1984 (remote workbench CNB/Lighthouse/Feishu), #2968 (self-hosted Mac target).

## Decision needed before any slice

1. **Which surface connects?** Desktop app → remote daemon? Or is plain `ssh` into the server plus a local install the documented interim answer?
2. **Transport shape:** in-process SSH crate vs shelling out to system `ssh` (keys, agent forwarding, ProxyJump come free with the latter)?
3. **Trust boundary:** key/agent handling, host-key verification, and what never crosses — `remote_control.rs`' posture (no credentials, paths, env, or arbitrary command strings across the boundary) is the bar to meet or explicitly revise.
4. **Scope split:** files + shell + git remote while model calls stay local? Or a full remote runtime with a thin client?

## Candidate slices (after the decision)

- **S0:** document today's answer if ssh-then-run-locally is the interim stance.
- **S1:** `codewhale exec --target ssh:` one-shot proof across the transport seam.
- **S2:** interactive TUI attach to a remote runtime daemon.
- **S3:** desktop parity.

Size: L/XL. Design first; do not start S1+ without settling the four questions above.

Start with crates/tui/src/remote_control.rs and docs/rfcs/REMOTE_SETUP_DESIGN.md, then review the four open decisions in the issue. This is design-first: done means the connection surface, transport, trust boundary, and scope are decided and a concrete implementation slice is documented before S1 or later work begins.

Written by the indexing model from the issue text.