ci: verify the build before committing refreshed data

The CI failure on the merge commit was the one-time bootstrap ordering
problem: `go run . -build` ran before any data/metadata.json existed. The
nightly updater has since committed one, so the tree builds — but that
commit was pushed with GITHUB_TOKEN, which by design does not re-trigger
workflows, so CI never re-ran and main's status stayed red.

That exposes a standing gap rather than a one-off: every nightly refresh
commits the exact data the build consumes, and none of those commits run
CI. A refresh that broke the build would first be noticed by Cloudflare
at deploy time.

Run `go run . -build` in the update workflow between the fetch and the
commit, so data that does not build is never committed. Add
workflow_dispatch to CI so a bot-pushed commit can still be verified on
demand.

.github/workflows/ci.yml

@@ -2,6 +2,10 @@ name: CI
 
 on:
   pull_request:
+  # Lets a bot-pushed commit be verified on demand: GITHUB_TOKEN pushes do not
+  # trigger workflows, so the nightly refresh otherwise leaves main's CI status
+  # reflecting the last human push.
+  workflow_dispatch:
   push:
     branches: [main]
     paths:

.github/workflows/update.yml

@@ -46,6 +46,14 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: go run .
 
+      # Bot commits are pushed with GITHUB_TOKEN, which by design does not
+      # re-trigger workflows — so CI never runs on them. Without this step a
+      # refresh that broke the build would be discovered by Cloudflare at deploy
+      # time. Running the build before the commit means unbuildable data is
+      # never committed in the first place.
+      - name: Verify the committed data builds
+        run: go run . -build
+
       - name: Commit changes
         run: |
           git config user.name  "github-actions[bot]"