feat(desktop): allow connecting Desktop to a remote kimi server (SSH dev boxes)

Summary

Kimi Code Desktop (1.0.0-beta.1) can only drive a server it embeds in-process on the local machine. For users whose real dev environment is a remote Linux box on a corporate intranet (dev servers, GPU machines), there is no way to point the Desktop GUI at a kimi web daemon running there. Today the only options are a browser tab, or Remote Control — which relays session content (diffs, file previews, terminal output) through Kimi's servers and requires a paid membership, which is a non-starter for code that must not leave the intranet.

Proposal: let Desktop connect to an existing/remote kimi server, so the agent, files and tool execution stay on the dev box while the Desktop UI runs locally — the VS Code Remote-SSH / JetBrains Gateway model. This is the complement of #3443 (which proposes a local engine with remote tool execution via RTS); both serve the same "my dev machine is remote" population.

Current behavior (1.0.0-beta.1)

• Desktop embeds kap-server and calls startServer() in-process (per #3812), binds 127.0.0.1:58627 (bumping +1 on EADDRINUSE), and loadURLs only its own origin.
• Settings → "Server address" is read-only (copy button only).
• Workspaces are local folders only; adoption of an already-running shared daemon is keyed on a local pid under ~/.kimi-code/server/, so e.g. an ssh -L tunnel squatting the port cannot work: Desktop's embedded server silently moves to the next port and the window still points at itself.

Why this should be cheap: the groundwork already exists

• The shipped renderer already honors ?kimi_origin=<url> (sessionStorage key kimi-desktop-server-origin) to retarget all REST/WS calls — this is exactly how the Remote Control tunnel page drives a foreign origin. What's missing is only a shell-level entry point to load a user-specified origin with kimi_desktop=1.
• The server API is documented (kimi-code-cli/reference/server-api.html) and kimi web already serves remote browsers with token auth (#token=, rotate-token, KIMI_CODE_PASSWORD).
• Community shells attaching to the same API already exist (#2955), and the former public apps/kimi-desktop shell (removed in #1849) shows the window.kimiDesktop bridge contract is origin-agnostic apart from loadURL.

Suggested increments (small → large)

1. "Connect to server…" in Settings (or onboarding): URL + token; shell loads <origin>/?kimi_desktop=1&platform=…#token=…. Minimal change, immediately useful with kimi web + SSH tunnel.
2. Documented env var / flag (e.g. KIMI_DESKTOP_SERVER_URL) for headless/enterprise provisioning. Note KIMI_SERVER_URL currently exists only as a dev/e2e knob.
3. Built-in SSH tunnel helper (host/user/key → local forward), so users don't hand-roll ssh -L and tokens never traverse anything but the tunnel.
4. Remote-bind capability story: bindClassify classifies non-loopback binds as public and disables the terminal PTY / debug / shutdown routes — so a remote-attached Desktop would lose its native terminal panel. A token-authenticated non-loopback bind that keeps PTY routes (the Desktop's own embedded server already runs --dangerous-bypass-auth on loopback; remote needs the opposite trade: auth on, PTY on) is required for feature parity.

Use case

• Remote Linux dev server holds the code, toolchain, GPUs and intranet-only dependencies; laptop holds the GUI.
• Compliance: session content must not transit third-party relays → Remote Control is excluded; direct browser works but loses the Desktop experience (native terminal, changes panel, approvals, workspace picker).
• Stability: relay handshake outages (observed 503 flapping at launch day) don't affect a direct connection at all.

Related: #3443 (complementary direction), #2955 (community shell), #3812 (embedded server), #1849 (desktop moved to private repo).

Start with the Desktop renderer's existing kimi_origin handling and the shell path around startServer() and loadURL(). Read kimi-code-cli/reference/server-api.html, then inspect bindClassify and the window.kimiDesktop bridge contract. Done should be a clearly scoped remote-server connection increment with authentication and behavior defined for the affected Desktop capabilities.