fix(ci): every publishing job builds the commit that fired the run, not the branch tip (#4427)

BUILD_REF resolved to the branch name on ordinary runs, and each job's
checkout re-resolves a branch when that job starts. A push that lands
mid-run therefore moved the later jobs onto the new tip:

- run 7499 signed 423275a's extension;
- its build-web then checked out 83e1382, derived a version nobody had
  signed, and got a 404 on the download.

The guard failed closed. A job without such a guard would have published
a commit the run's lanes never tested.

The lanes already check out github.sha by default. BUILD_REF is now
github.sha on every trigger except the base refresh, which keeps `main`
and its branch guard. The publish therefore builds exactly what the
lanes passed.

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

ci-requirements.md

@@ -180,7 +180,10 @@ 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. Every job then ASSERTS its checkout is `main`
+    that exists perfectly well. On every other trigger `BUILD_REF` is the
+    triggering COMMIT (`github.sha`), not the branch: a branch is re-resolved
+    per job, so a push landing mid-run used to move the publishing jobs onto a
+    commit the run's lanes never tested (run 7499, #4427). 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