Spinbox opens workspaces through a remote resolver of its own, so a connection's failures are ours to see and fix #24

Today a workspace opens through Microsoft's Remote-SSH, via ssh config and spin as ProxyCommand. Its connection errors are opaque, and a refusal is seen only in logs. The end-to-end experience is not ours to see or fix.

Decided

• A separate fork, a dependency of this extension: spin-stack/open-remote-ssh, the extension spin-stack.spinbox-remote (Spinbox Remote), MIT with attribution. It keeps only what opening a Spinbox workspace uses: no ssh-remote resolver, ~/.ssh/config, server download, tmux or clipboard bridge.
• Microsoft VS Code stable only (dd3b67d, open-remote-ssh#5): no VSCodium, no Open VSX. The resolver uses the proposed resolvers API, which the Marketplace refuses, so it is a signed VSIX on the GitHub release that spin vscode install installs, enabled by argv.json enable-proposed-api. Without it, Remote-SSH stays the fallback, and this extension says once how to enable it.

Done

• Fork and tidy to the stack's standards (open-remote-ssh#1).
• A Spinbox resolver (open-remote-ssh#2, Say a key the keyring does not list, and a machine with no key, with what fixes each #3, versions: spin v20261106.01, the release spinbox.dev runs #6, publish: push each release to the public package spin vscode install reads #8): authority spin+<workspace>; spin code, spin ssh-session, ssh over spin tunnel with this machine's OpenSSH; the host key pinned to the launch claim; the server from the extension disk, never downloaded; refusals shown in VS Code with their action.
• Opened as spin+ when the resolver is active, Remote-SSH otherwise (e283cf1, 901bfaf).
• Published on the GitHub release (open-remote-ssh#4, Publish: a GitHub release of every tag, before the registries #5).
• The resolver's core against a real stack and the real CLI (open-remote-ssh test/e2e): opens, reconnects to the same server, stopped, key not enrolled.

Left

• The harness in a real VS Code (test: spin+ in a real VS Code against a spin e2e stack #37, test: the dashboard's link brings the open window, a move, and windows quit as a person quits #38): task test:spin-remote covers running, stopped, a reconnect (back in about 1 s with the same terminal shell), a refused key said once, and the dashboard's link. It found that remote.spin.cliPath and spinbox.cliPath were machine-scoped, so a reconnect ran another spin (open-remote-ssh#17, test: spin+ in a real VS Code against a spin e2e stack #37).
• Moved host: the moved case is in the lane (CASES=moved, after spin's e2e:hosts:up) and fails on spin#1225: the reconnect's start resumes the workspace while the move has it suspended, and the move aborts.
• Reuse an open window (from spin#1119, test: the dashboard's link brings the open window, a move, and windows quit as a person quits #38): VS Code already brings the window open to the folder Spinbox opens, the dashboard's link by id included, though openFolder asks for a new one. The lane's reuse case holds it.
• Telemetry: the resolver's connection as spans under the traceparent this extension already hands the CLI, off when VS Code's telemetry is.
• Terminals that survive a disconnect or a move: sessions held by the supervisor (decided), which needs a spin issue first. A reconnect already keeps the terminal's shell, as long as the server lives.

Done when

The harness opens, reconnects and fails a workspace (stopped, refused key, moved host) on a real stack and asserts what the person sees.