Run the data build from main only, sync from the lock, publish one release per build

[baz8080]

PR G of the fixes from the retroactive review: CI safeguards, a publish that can't leave the latest release without a DB, and the removal of the closed_at replay input.

Changes

• Main only. A Build DB dispatch from anywhere other than main is refused by its own job, which fails visibly. The build-db concurrency group sits on the build job, so a refused dispatch can't displace a queued scheduled run. pages.yml also requires workflow_run.head_branch == 'main'.
• uv sync --locked in all three workflows, with uv pinned to 0.12.18 next to the setup-uv commit SHA.
  • 0.12.18 passes uv lock --check on the current lock and installs CPython 3.14.7.
  • An earlier pin, 0.8.17, would only have offered 3.14.0rc2.
• One release per build (owner decision).
  • Every data build publishes its own release, tagged YYYY-MM-DD-HHMM (UTC), with gh release create --latest.
  • gh creates the release as a draft, uploads and then publishes it, so the latest release always holds a complete uisce.db. That is about two releases a day instead of one.
  • This replaces gh release upload --clobber, which deleted the old asset before uploading, so a failure in between left the day's release with no DB.
  • scripts/publish-db.sh and scripts/fetch-db.sh are now the only way to publish or download. Both workflows, the README, pipeline-dependencies.md and build.py's refresh hint use them.
• astral-sh/setup-uv pinned to its commit (c771a70, tag v9.0.0). It runs in the job with contents: write.
• The replay_closed_at dispatch input and its step are removed (owner decision).
  • A dry run over all 75 releases found 0 values to stamp or change.
  • The script stays, run by hand. It now reads the date from the tag's first 10 characters, sorts snapshots by tag, and its documented loop excludes drafts.

Review

First round, 10 findings. The first design replaced the asset inside a per-day release by uploading under a temporary name and renaming. The review found four failure paths in that swap, and those fixes led to the swap being moved into scripts.

Second round, 10 findings. It found three more states the swap could strand:

• the recovery view's errors were swallowed;
• no recovery ran before the download step;
• both copies could be present at once, and the stale one was then used.

All three came from juggling two names inside one release, so the owner chose one release per build. That removes the swap and the fallback, and with them 7 of the 10 findings.

The other three:

• the uv pin landed on a Python release candidate;
• the asset name depended on the file name (the # suffix in gh release create is only a display label, per gh's source);
• a download recipe in notes/pipeline-dependencies.md had been missed.

Also found while testing: snapshot file names sort 2026-09-24-1845.db before 2026-09-24.db, so the replay now sorts by tag, and a test covers it.

Verification

• shellcheck and actionlint pass.
• uvx uv@0.12.18 lock --check passes.
• A fake gh exercised: a publish (the previous release untouched), a second publish in the same minute (refused), a DB file under another name (still published as uisce.db), and a fetch.
• uv run ruff check and uv run pytest pass: 687 tests, merged with current main.
• The first real run is the next scheduled Build DB after merge. I'll check its release and the Pages deploy.

Notes

• data-quality.md:
  • "The replay has nothing left to recover (2026-09-24)";
  • "One release per build (2026-09-24)", including the rejected swap.
• CLAUDE.md: rows for the replay input and for one release per build.

🤖 Generated with Claude Code

https://claude.ai/code/session_0168hLW2X3mkV3Jhm26LJSwQ