Publish to a self-hosted gallery at gallery.fallout.build

Start with IPublishVsix, VsixPublishTarget, VsixRegistry, and the --publish-vsix-to selector, then inspect the existing VsceTasks/OvsxTasks and per-channel environment pattern. Resolve the gallery choice and its infrastructure in Homelab#409 first; done means a working gallery environment, HTTPS endpoint, and publishing target with automatic preview updates.

Idea / not scheduled. The extension-side half of Chrison-Homelab/Homelab#409, which tracks standing a gallery up at all.

Why

The pipeline already has three channels — rolling preview, github-releases, and the two marketplaces behind approval gates. What none of the GitHub ones can give is automatic updates: VS Code only tracks versions for extensions it got from a gallery, so a .vsix downloaded from a release is a one-shot install forever.

A gallery at gallery.fallout.build would make the preview channel behave like a real extension feed — install once, updates thereafter — without needing a public marketplace presence for pre-release builds.

What it would need here

• A fourth publish target. IPublishVsix already models registries as data (VsixPublishTarget + VsixRegistry) and the --publish-vsix-to selector already exists, so this is a new enum value plus a target entry, not a new pipeline.
• How publishing works depends on which gallery (see #409):
  • Microsoft Private Marketplace — extensions are published by dropping .vsix files into the container's storage (mounted volume or Azure Artifacts), not through a CLI. That's a copy/upload step, so it likely wants its own small tool wrapper or task rather than reusing VsceTasks/OvsxTasks.
  • Open VSX — OvsxTasks covers it today via SetRegistryUrl. Zero new tooling.
  • coder/code-marketplace — has its own CLI for adding extensions.
• A gallery environment in the repo, matching the existing per-channel environment pattern. Ungated seems right for an in-house preview feed.
• HTTPS on gallery.fallout.build — VS Code refuses a plaintext gallery, so this needs a real certificate.

Decision to make deliberately

A gallery on the project's own domain implies public-read, which makes it a genuine third distribution channel rather than a homelab convenience. That's a different security posture from "my network", and it matters because no gallery option supports authentication with VS Code — access control can only come from the network layer. Publishing Fallout extensions to a public gallery.fallout.build means anyone who knows the URL can consume them.

If the Microsoft option is chosen, there's a second constraint: consumers need a GitHub Copilot Enterprise/Business or GitHub Enterprise seat to connect at all, which makes it unsuitable as a public channel and fine as an internal one.

Note on the version scheme

No version-scheme change needed. The patch component is a Nerdbank.GitVersioning git height, so every build already carries a unique number and a gallery can hold the whole sequence without collisions. This is also why publishing previews as pre-release never consumes a number a stable release wants.

Blocked on

Chrison-Homelab/Homelab#409 — the gallery has to exist first. Options and trade-offs live there rather than duplicated here.