[FEATURE]: SSH-based remote server connections to OpenCode Desktop

[dl-alexandre]

Feature hasn't been suggested before.

• [x] I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Summary

Add first-class SSH connectivity to the OpenCode desktop app so users can connect to a remote opencode server through a secure SSH local port-forward. The desktop app continues to speak HTTP/WebSocket to the server via 127.0.0.1:<localPort>; SSH is transport only.

Goals

•	Establish SSH local port-forwards using the system ssh binary (no embedded SSH libs).
•	Discover a running remote OpenCode server via a standardized health endpoint over the forwarded port.
•	Optionally bootstrap a server via a single remote command execution (no interactive shell workflow).
•	Provide clear connection states, diagnostics, and typed error surfaces.

Non-goals

•	Remote filesystem access beyond the OpenCode server API.
•	Terminal multiplexing / interactive shell access.
•	SSH key generation/management/storage.
•	SSH config modification/management.
•	Remote extension execution.
•	Any custom SSH protocol implementation.

Proposed UX

•	“Add Connection” wizard for creating a Connection Profile (host + optional user/port/identity file/proxy jump).
•	Connect/Disconnect per profile.
•	Connection status indicator (Connecting → Discovering → Bootstrapping → Connected / Failed).
•	“Copy Diagnostics” action (redacted logs + effective parameters used).

Requirements (high-level)

SSH Transport

•	Use system ssh to establish a local forward bound to 127.0.0.1 (local endpoint only).
•	Fail fast if ssh would prompt for a password/passphrase (no password prompts in-app).
•	Host key verification must be enabled (StrictHostKeyChecking equivalent). Unknown host keys require manual acceptance via ssh outside the app.
•	Clean termination on disconnect (SIGTERM then SIGKILL after timeout).

Discovery

•	After tunnel is established, probe a standardized endpoint (e.g., GET /health) through the local forward.
•	Require 200 OK and JSON including at least status and version.
•	Enforce compatibility (e.g., major version mismatch fails with a Compatibility error).
•	Timeouts and retry rules should be defined (initial suggestion: 10s per probe).

Optional Bootstrap

•	If discovery fails and bootstrap is enabled, run a single remote command (e.g., opencode server start --port=<p> --json).
•	Parse JSON output for port/endpoint data, then retry discovery.
•	No user-provided arbitrary command args beyond a port number.
•	Timeout bootstrap (initial suggestion: 30s) and surface stderr/stdout in diagnostics (redacted).

Profiles & Integration

•	Persist profiles locally (JSON in app data dir).
•	Support SSH config options commonly needed: Host, HostName, Port, User, IdentityFile, ProxyJump.
•	Respect known_hosts; never modify SSH config or known_hosts.

Error Taxonomy / Diagnostics

•	Typed errors: Transport, Discovery, Bootstrap, Compatibility, Configuration.
•	Expose actionable messages + include redacted raw ssh stderr/stdout in diagnostics.

Open Questions

•	How to choose the remote server port (default vs negotiated if 8080 is in use)?
•	Whether to support multiple forwards (if bootstrap returns a different port) vs rebuild tunnel.
•	What exact /health JSON contract should be considered stable/minimum?
•	Precedence rules: profile values vs ~/.ssh/config Host entries.

Acceptance Criteria (MVP)

•	User can connect to a host with an already-running remote OpenCode server using an SSH tunnel created by the desktop app.
•	If server not running, user can optionally bootstrap it and then connect.
•	Errors are typed and diagnosable without exposing secrets.