ci: assert the scheduled refresh actually checked out main

BUILD_REF is read through the `env` context inside `with:`, which this
runner is not known to evaluate. `${{ steps.* }}` and `${{ secrets.* }}`
in `with:`/`env:` are proven here; `env` is not, and run 4915's checkout
log (`git checkout -B dev refs/remotes/origin/dev`) cannot tell an
honoured `refs/heads/dev` from an empty value falling back to the same
place — the two are indistinguishable on every path except the one that
matters.

If it does resolve empty, the weekly refresh checks out dev and pushes
its source to :latest, which is production. Every lane stays green and
the first symptom is production running code that was never merged.

So each of the four jobs now asserts its own checkout before doing
anything, gated on `github.event_name` — the `github` context is
demonstrably evaluated in `if:`, so the guard cannot be disabled by the
same uncertainty it covers. A red weekly job is an acceptable outcome;
shipping dev to production is not.

ci-requirements.md

@@ -178,7 +178,11 @@ per `docs/process.md`'s "add deps to the image when used by >1 project".
     BUILD_REF` that every checkout in the file takes, rather than per job —
     otherwise `sign-extension` would derive dev's extension version while
     `build-web` bundled main's, and the release download would 404 on a version
-    that exists perfectly well.
+    that exists perfectly well. Every job then ASSERTS its checkout is `main`
+    before doing anything, because `env` inside `with:` is not a context this
+    runner is known to evaluate — if it silently resolved to empty, checkout
+    would fall back to the triggering ref and the refresh would publish dev's
+    source to `:latest` with every lane green.
   - It **publishes only `:latest`.** `:c-<sha>` for main's HEAD already names
     the bytes that commit built; re-pushing it over refreshed layers would
     break the one tag rule 145 makes immutable, and it is the rollback unit.