Phase 1: WinUI-Gallery publishes a sample index (and we delete GalleryFetcher)

@Jaylyn-Barbee is already working on this.

Since Sep 2, 2026.

Parent: #703

Get `microsoft/WinUI-Gallery` publishing a machine-readable sample index, then consume it and delete our scraper. This phase is **not done until `GalleryFetcher.cs` is deleted**.

Gallery goes first. The original issue suggested leading with CommunityToolkit, but research inverted that: Toolkit's generator cannot emit JSON and does not hold the sample code, while Gallery's maintainer has already published the intent.

> **Revised 2026-09-09.** The sample layout, the file counts, the payoff and the acceptance test were re-measured against `microsoft/WinUI-Gallery@main` and against our committed corpus. Three of the original claims did not survive that check — most importantly, the malformed-XAML payoff was backwards. All are corrected below; see the comment thread for the measurements.

## Why Gallery is the proof point

microsoft/WinUI-Gallery#2167 ("Restructure samples", marcelwgn, merged 2026-05-16) says in its own body:

> The `--- type` marker format is designed to be extensible. In a future change, metadata like title and description could also be inlined in the same file (e.g. `--- title`, `--- description`), allowing a single file to fully describe a control example

That is this ask, stated upstream, unprompted, by the maintainer who did the restructure. Supporting evidence: single repo, no submodule, no CODEOWNERS gate, routine PRs merge in 1–3 days. No existing issue or PR on that repo asks for a sample index, so the ask is unclaimed.

## The ask: a sibling file, not an inline change

Do **not** ask them to inline sample bundles into `ControlInfoData.json`. That file is deserialized synchronously at app startup and is 168 KB today; inlining would take it to roughly 530 KB on the startup hot path, and it would convert snippet loading from lazy (on navigation) to eager for zero in-app benefit.

Ask instead for a sibling `WinUIGallery/SampleSupport/Data/SampleIndex.json`, generated and checked in, with a `SampleIndexSchema.json` alongside it — following the `ControlInfoDataSchema.json` precedent the repo already sets.

## The sample layout we have to read

Samples live next to their page files, keyed by **control name**:

```
WinUIGallery/Samples/AppBarButton/
AppBarButtonPage.xaml
AppBarButtonPage.xaml.cs
AppbarbuttonKeyboardaccelerator.txt <- bundle, with --- header / --- xaml / --- c# markers
```

| Set | Files | Notes |
|---|---|---|
| Bundles (`Samples/{ControlName}/*.txt`) | 316 | 288 carry a `--- xaml` marker; the other 28 are C#-only |
| Legacy (`Samples/SampleCode/*.txt`) | 164 | **zero** carry any `--- ` marker — a genuinely different format |

The legacy set is nearly dead: `ControlInfoData.json` references `SampleCode` **zero** times, and only **two** XAML pages in the whole repo still set `CodeSourceFile` (resolved against `Samples/SampleCode/` by `SampleCodePresenter.xaml.cs`). So supporting both formats is much cheaper than the raw file count suggests, and it is worth asking upstream whether those 164 files are simply leftovers from #2167 that can be deleted.

## Shaping constraints

- Gallery CI is Azure Pipelines with no GitHub Actions, and the official pipeline is internal. So the PR must be a **checked-in generated artifact plus a validation step**, not build-time generation an external contributor cannot exercise.
- The generator should be a standalone .NET tool under `tools/`, deliberately **not** added to `WinUIGallery.slnx` — that solution maps every project across 8 build types x 4 platforms, and staying out of it keeps the tool off their build graph.
- It must handle both sample formats described above.

## Payoff

**Size and request count.** Deletes 665 lines of scraping, and takes a Gallery cold fetch from up to 433 requests to 1. This is the whole of the case for the index.

**Not correctness.** An earlier version of this issue claimed publishing "eliminates the malformed-XAML class of bug by construction," on the theory that bad output comes from splitting samples out of XAML pages heuristically. Measurement says the opposite — see the comment thread for method:

| | Count |
|---|---|
| Structurally broken scenarios in our corpus | 10 |
| …caused by **upstream** source files | **8** |
| …caused by **our scraping** | **1** (`xamlresources-3`) |
| …not a real defect (deliberate `` where `AppBarButtonPage.xaml:95-97` has the correct ``.
2. **Corpus-boundary validation is a prerequisite of "consume the published index," not a nicety** — otherwise this phase regresses snippet quality by unmasking those five.

## Steps

- [x] Fix the 13 malformed sample bundles upstream — a standalone PR that needs no artifact, sent before the index ask. Source each fix from the neighbouring `{Control}Page.xaml`
- [x] Propose a XAML well-formedness check upstream so they cannot regress. It must tolerate deliberate elisions such as `