Add the snapshot builder and its publish

[Maximilian-Nesslauer]

Closes #7.

The snapshot of spec/snapshot.md, published to Pages at /v1/index.json.

The builder joins each listing to its release files, filters a delisted listing down to a tombstone, and attaches the index status.

Rebuilding the design repository's examples/ gives 29,806 bytes where the spec predicts "about 30 KB" for that exact input, byte-identical across two runs, and the StarMap entry matches the spec's worked example key for key, including no install object on a loader's release file.

• Pages is already set to "GitHub Actions", so the deploy job goes live with the merge.

[averageksp]

1. One malformed input anywhere stops the whole index from updating: a dangling id in index-status.toml, a release file that does not parse, a listing whose id disagrees with its file name. That is the right direction, and the failure is loud, but it has a sharp edge on the moderation path specifically: a steward's typo in a delisting means the delisting does not reach clients and the old snapshot keeps serving the content they wanted gone, until somebody notices the red run.
2. A release folder belonging to no listing is only a note in the log. So renaming a listing silently drops its releases out of the snapshot. That matches the spec, which says listed entries only, but it is a quiet failure mode.
3. The build job mints the App token, which carries write on both repositories, while the job only reads and both repositories are public. It could use the default token or none at all. Optional hardening, not a hole, since nothing untrusted executes in that job.
4. There is no index.html, so the Pages root 404s and only /v1/index.json answers. Fine by the contract, maybe worth a one-line landing page later.
5. actions/configure-pages is not used, which is correct while Pages is set to "GitHub Actions". If that setting ever changes, the deploy fails loudly rather than silently publishing nothing.