D9: platform-specific VSIX targets with prebuilt node-pty — THE 1.0 distribution gate

[rappdw]

The vsix ships node-pty built for the publishing machine only; everyone else hits posix_spawnp failed. (ROADMAP_1.0.md D9; flagged as a blocker in the original spike).

Work:

• CI matrix producing per-target packages: vsce package --target darwin-arm64 darwin-x64 linux-x64 linux-arm64, each containing node-pty built for that platform against the supported VS Code Electron ABI range.
• Decide prebuild strategy: compile-in-CI per target (electron-rebuild in the matrix) vs adopting a prebuilds-shipping node-pty; document the Electron-major support window and the policy for when VS Code bumps it.
• Local dev path (install.sh) unchanged.

Acceptance: installing the right target vsix on a clean machine of each platform launches sandy with zero rebuild steps; code --install-extension picks the right target from Marketplace automatically. Size L — the only genuinely hard engineering left before 1.0; can start in parallel with 0.7/0.8.

[rappdw]

Add a requirement from the Remote-SSH investigation (#37): the target matrix must include a remote-host target — node-pty built for the VS Code Server's Node.js ABI, not just the four local Electron-ABI desktop targets.

Running sandy-ui against a remote sandy (the DGX) over Remote-SSH puts the extension host on the remote, under the server's bundled Node.js runtime — a different ABI than the local Electron install. A desktop-target vsix installed into the remote host fails with posix_spawnp failed. Until this exists, the remote workflow requires building from source on the remote (documented in #37). So D9 is: darwin-arm64/x64 + linux-x64/arm64 (Electron ABI, local) plus a linux server-node target (or a node-pty that ships prebuilds spanning both ABIs). Evaluate whether @vscode/…-style prebuilds or a matrix compile covers the server-node case.