Refresh the catalogues on a schedule, and republish when they change

Mondays 05:23 UTC: re-run the ETL cold against the live archives, and if the
output differs by a byte, gate it on the unit suite and a production build,
commit it to main, and dispatch the Pages deploy. If nothing changed, say so
in the run summary and touch nothing.

The gates run inside this workflow because they cannot run after it: a push
made with GITHUB_TOKEN fires no push workflows at all — GitHub's recursion
guard — so an unguarded push would deploy nothing and be checked by nothing.
The same guard is why the deploy and a visible CI record are dispatched
explicitly afterwards; dispatch events do go through where push events do
not. ci.yml gains a workflow_dispatch trigger for exactly that call.

Also corrects pages.yml's claim that configure-pages enables Pages on first
run. It cannot: the action's `enablement` input requires an admin-scoped
token, which GITHUB_TOKEN is not. If the site has never been enabled, the
first deploy fails at that step and the one-time fix is Settings → Pages →
Source: GitHub Actions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G

.github/workflows/pages.yml

@@ -34,7 +34,10 @@ jobs:
 
       - run: npm ci
 
-      # Enables Pages on first run if it is not on yet, and reports the URL the site will live at.
+      # Verifies Pages is enabled and reports the URL the site will live at. It cannot *enable*
+      # Pages itself: the action's `enablement` input requires an admin-scoped token, which the
+      # workflow's GITHUB_TOKEN is not. If this step fails with "Get Pages site failed", the
+      # one-time fix is Settings → Pages → Source: GitHub Actions, then re-run.
       - uses: actions/configure-pages@v6
 
       # A project site is served from a subdirectory, so the app cannot assume it sits at the