Ship the VS Code extension to the Marketplace

[jscaltreto]

Summary

Track the remaining work required to ship the VS Code extension to the Visual
Studio Marketplace from a maintainable release path.

Current state in this repo

The extension is further along than this issue originally captured.

• editors/vscode/package.json already has a publisher, version, Marketplace
  metadata, and a local packaging flow via npm run package.
• editors/vscode/scripts/package.mjs stages and packages a .vsix locally
  with vsce.
• CI already validates the extension in .github/workflows/vscode.yml by
  running npm ci, npm run lint, npm run compile, and npm run package.
• Marketplace-facing basics are already present: extension README.md,
  SUPPORT.md, icon asset, and the shared root CHANGELOG.md copied into the
  staged extension package.
• The Marketplace publisher decision is settled enough to proceed with
  publisher: jscaltreto.

Decisions already made

• Publish from this repo's editors/vscode/ subtree. Splitting to a dedicated
  repo is unnecessary churn unless release management proves painful.
• The VS Code extension tracks the main Go release version. One release
  version, one bundled binary version, one release flow.
• The extension changelog is the root CHANGELOG.md, copied into the staged
  extension package at build/package time rather than maintained separately
  under editors/vscode/.

Remaining blockers before first Marketplace release

• Create an Azure DevOps PAT with Marketplace (Manage) scope.
• Store that PAT as the VSCE_PAT GitHub Actions secret.
• Add a publish workflow using vsce publish.
• Make sure the extension package version matches the release tag / release
  automation output.
• Decide whether first release is Visual Studio Marketplace only or also Open
  VSX.
• Bundle platform-specific downstage binaries in platform-targeted VSIX
  packages if we want zero-install CLI setup for users.
• Run end-to-end install validation from a packaged .vsix before first
  publish.

Child issue status

• #49 docs(vscode): Marketplace presentation and metadata
• #47 chore(vscode): set up Marketplace publisher and publish workflow
• #50 test(vscode): pre-release validation and smoke tests

Recommended order

1. Finish #47 first. The release path is still the real blocker.
2. Then run #50 against the actual packaged publish candidate.
3. Bundle binaries as a follow-on if we decide first release must avoid a
   separate CLI install.

Sources

• VS Code publishing docs:
  https://code.visualstudio.com/api/working-with-extensions/publishing-extension
• VS Code CI docs:
  https://code.visualstudio.com/api/working-with-extensions/continuous-integration

[jscaltreto]

Subtasks

This issue is now a tracking epic. The work has been broken into independent subtasks:

1. chore(vscode): add CI workflow for extension lint/compile/package #46 — CI workflow for extension lint/compile/package (do first — foundation for everything else)
2. chore(vscode): set up Marketplace publisher and publish workflow #47 — Marketplace publisher account and publish workflow
3. feat(vscode): bundle release binaries into platform VSIX #48 — Bundle platform-specific downstage binaries in VSIX
4. docs(vscode): Marketplace presentation and metadata #49 — Marketplace presentation and metadata
5. test(vscode): pre-release validation and smoke tests #50 — Pre-release validation and smoke tests

Dependency graph

#46 (CI) ──┬──→ #48 (binary bundling) ──→ #50 (validation)
           │
#47 (publisher) ─→ #48 (binary bundling)
#49 (presentation) ─────────────────────→ #50 (validation)

#46 and #47 and #49 can all be worked in parallel. #48 needs CI and publisher plumbing in place. #50 is the final gate before publish.