[Feature]: Continue a local agent on Orca Cloud or another host

### Problem or use case

Orca already has building blocks for running projects and workspaces away from the current machine: SSH hosts, paired Orca runtime environments, and experimental Per-Workspace Environment recipes. However, execution placement is still something users largely choose up front, through separate setup flows.

Once an agent is already working locally, there is no simple way to continue that same task on another machine. Moving it manually means recreating the workspace remotely, transferring committed and uncommitted state, repeating setup, reconstructing the agent's context, and then making sure the local and remote copies do not diverge.

This blocks a valuable workflow:

- start a task locally while exploring or prompting interactively
- move it to a remote machine before closing the laptop
- let multiple agents continue without using local CPU, memory, or battery
- reconnect from another Orca client or mobile device to monitor, steer, and review the result

Cursor recently presented this as moving a local agent to the cloud so it can keep working with the laptop closed: https://x.com/cursor_ai/status/2067366343817805899

**Short summary:** add a first-class way to choose where an agent runs and to hand an active local workspace off to Orca Cloud, a paired Orca server, an SSH host, or a configured per-workspace environment.

### Proposed solution

Add a unified execution-target control in two places:

1. A **Run on** selector when creating a workspace or starting an agent.
2. A **Continue on…** action for an existing workspace or active agent.

The destination list could include:

- This machine
- configured SSH hosts
- paired Orca servers/runtime environments
- configured Per-Workspace Environment recipes
- an optional managed **Orca Cloud** destination, if Stably chooses to offer hosted compute as a paid service

A handoff should:

1. **Preflight the destination** — verify connectivity, repository access, compatible Orca/runtime version, agent availability, setup recipe, and required capabilities.
2. **Recreate the workspace safely** — preserve repository identity, branch/base commit, staged changes, unstaged changes, untracked files, file modes, and the current task/session metadata.
3. **Resume rather than pretend to migrate a process** — start a fresh agent process remotely with the resumable conversation/goal and a handoff summary. A live PTY or in-memory process does not need to move bit-for-bit.
4. **Keep secrets destination-owned** — do not silently copy local credentials or environment files. Show missing requirements and use the remote host's configured accounts, vault, or setup recipe.
5. **Cut over atomically** — keep the local workspace intact until the remote workspace is ready and acknowledged. If setup fails, leave local work running and offer retry or cancellation.
6. **Preserve the Orca experience** — keep the same workspace card and history, update its host badge/status, and route terminals, files, source control, ports, and agent controls through the new owner.
7. **Run independently of the laptop** — once moved, the destination must own the filesystem and agent process; the local machine should not remain a required proxy.

A useful first slice could target configured SSH hosts and paired Orca servers, because users can bring their own always-on machine. Managed Orca Cloud could use the same destination and handoff model later.

### Alternatives or additional context

**Current workaround:** commit or stash the local changes, create/open a separate remote workspace, restore the changes, rerun setup, restart the agent, and manually copy enough conversation context for it to continue. This is slow and easy to get wrong, especially with untracked files or partially completed work.

**Hosted-only alternative:** Orca could provide a managed sandbox backend and charge for compute. This is convenient, but making execution targets pluggable would preserve Orca's local-first model and support teams that already have an SSH host, private server, or cloud account.

**BYO-host-only alternative:** implement the handoff against existing SSH/Orca hosts without a Stably-hosted service. This delivers most of the workflow while leaving a managed destination open later.

Orca's existing source structure suggests some useful foundations already exist: runtime RPC can target local or a saved environment, SSH providers already route terminal/filesystem/git operations by connection, and Per-Workspace Environment recipes can create remote workspaces. The missing product and lifecycle layer is moving an existing workspace's state and agent context between those owners.

Related requests:

- #5497 covers making Orca cloud/Vercel VM support more visible.
- #2814 covers per-workspace cloud machines, warm pools, and provider architecture.
- #7208 covers remote/mobile connectivity through a cloud relay.

This request is specifically about the **execution-target selector and local-to-remote handoff semantics**, including user-owned hosts, rather than requiring any one cloud provider.

Additional reference: Conductor's Cloud Workspaces run new workspaces on remote Vercel Sandboxes while keeping the interface consistent: https://vercel.com/blog/how-conductor-moved-parallel-coding-agents-from-the-laptop-to-the-cloud-with-vercel-sandbox