Phase 2: CommunityToolkit publishes a sample index (and we delete ToolkitFetcher)

Parent: #703

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

This goes **after** Gallery (#809). The original issue called Toolkit the low-effort path; research showed the opposite.

## Why this is not the short path

- **`ToolkitSampleMetadataGenerator` cannot write JSON.** It is an `IIncrementalGenerator`, and `ctx.AddSource()` accepts C# source text only. Its entire output surface is `ToolkitSampleRegistry.g.cs` and `ToolkitDocumentRegistry.g.cs`. `CommunityToolkit.Tooling.SampleGen.csproj` targets netstandard2.0 with Roslyn only and references no JSON library. A JSON emitter has to be a separate MSBuild task, a standalone tool, or a CI script — not a generator tweak.
- **The generator never holds the sample code.** `ToolkitSampleMetadata` carries `Id`, `DisplayName`, `Description` and then runtime members that cannot be serialized without building the assembly. The actual `.xaml` / `.xaml.cs` / `.md` text ships as `Content` items and is read at runtime from `ms-appx:///SourceAssets/...`. The thing we most need is not in the assembled metadata at all.
- **Process is heavier.** All sample tooling lives in `CommunityToolkit/Tooling-Windows-Submodule`, consumed via a `tooling/` submodule, so a tooling change is two PRs. The `Windows` pin has run ~3 months behind tooling main, which is real delivery risk on top of review time.

## Approach

- Discussion first. `Contributing.md` routes feature work to Labs-Windows Discussions and `PULL_REQUEST_TEMPLATE.md` requires a linked issue — a cold PR gets closed. Use an issue or `aka.ms/wct/discord`.
- Prefer a single CI-script PR in `CommunityToolkit/Windows` over the two-PR tooling route purely to dodge the submodule lag, while being explicit that tooling is the better long-term home if they would rather own it there.
- The index must carry `curatedKeywords` separately from `keywords`. Toolkit is the only source with author-written keywords, and our search weights them at 5.0 versus 3.0 for tags; folding them together silently re-ranks results.

## Steps

- [ ] Open a discussion, referencing the Gallery index as the proof point
- [ ] PR: generator + index + validation
- [ ] Consume the published index in winappCli
- [ ] **Delete `ToolkitFetcher.cs` (1,000 lines) and retire the 34-entry `SampleOverrides` table**

## Payoff

Removes 1,000 lines of scraping and takes a Toolkit cold fetch from ~105 requests to 1. Retiring `SampleOverrides` is the specific win here: control ids would come from validated `[ToolkitSample(id:)]` attributes and `.md` frontmatter instead of being guessed from filenames, so a newly added Toolkit sample stops getting a wrong name until someone notices.