web/catalog.json snapshot predates the 2026-08-06 reload, so deployed metadata row counts are stale

## Problem

`web/catalog.json` is the only metadata source for the deployed frontend (CloudFront → S3; the relay implements only `/health` and `/ask`, so `/api/catalog` returns 403 and the UI falls back to this static file). The committed snapshot was generated **2026-08-04 09:44:36**, before the 2026-08-06 data fix and reload, so its row counts are stale:

| Field | catalog.json | Actual (post-reload) |
|---|---|---|
| `payments` rows | 691,800 | 689,255 |
| `totals.rows_all_layers` | 96,491,202 | 91,294,056 |
| derived layer | old values | derived shrank from 16,348,624 to 11,154,023 overall |

Effect: visitors to the deployed demo see pre-fix numbers, while `docs/` and `knowledge/connection.md` state post-fix numbers. Two sets of numbers in one demo — exactly the "silently drifting metadata" failure mode this project has been working to eliminate.

## Reproduce

```bash
python3 -c 'import json;d=json.load(open("web/catalog.json"));print(d["generated_at_utc"], d["totals"]["rows_all_layers"])'
# 2026-08-04 01:44:36 UTC 96491202
```

Compare against the 91,294,056 in `knowledge/connection.md:47-58` and `docs/data-walkthrough.md:44-48`.

## Suggestion

Regenerate and commit the snapshot:

```bash
python3 scripts/deploy/build_catalog_json.py # queries Glue, ~1 min
bash scripts/deploy/deploy_web.sh # or --fresh to do both
```

The "refuse to write a degraded snapshot" gate inside `build_catalog_json.py` is a good design, but it guards against `source` falling back to `information_schema` — it does not guard against **the snapshot itself being stale**. Consider adding a peer check: have `deploy_web.sh` compare `catalog.json`'s `generated_at` against `meta_snapshot.built_at` (or the reload timestamp) and refuse to deploy when the snapshot predates the data. That way "forgot to regenerate the snapshot after a reload" stops depending on someone remembering.

Start with scripts/deploy/build_catalog_json.py and scripts/deploy/deploy_web.sh, then inspect web/catalog.json and the stated timestamps in knowledge/connection.md and docs/data-walkthrough.md. Verify the regenerated snapshot reflects the post-reload counts, and ensure deployment cannot proceed with metadata older than the relevant reload or meta snapshot timestamp.

Written by the indexing model from the issue text.