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

Idea / not scheduled. The extension-side half of [Chrison-Homelab/Homelab#409](https://github.com/Chrison-Homelab/Homelab/issues/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](https://github.com/Chrison-Homelab/Homelab/issues/409) — the gallery has to exist first. Options and trade-offs live there rather than duplicated here.

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.

Written by the indexing model from the issue text.