actions.lock: four leaf entries still carry ref: <their own SHA> (#1271 follow-up) — every caller of the hypatia-scan / scorecard / codeql reusables dies at "Set up job" #1290

Follow-up to #1271 (f335165a8882, "leaf entries need a tag ref, not the pin's own SHA").

#1271 corrected nine leaf entries and closed with "the four stale unreferenced
entries are left untouched." Those four are not stale and not unreferenced. At
main = e16a23170fa378bf3b1444c3ee94100413ae3ff7 (checked 2026-10-18)
.github/workflows/actions.lock still carries six entries whose ref: is the
pin's own 40-hex SHA. Two of them are hyperpolymath/standards@… caller-side
entries, which are fine as-is. The other four are third-party actions, and each
one is reachable from a reusable workflow that estate repositories call:

(Reachability read from the workflows: section of the same lockfile.)

Measured failure

metadatastician/selur, main, run
39124697083,
2026-10-18T11:48:08Z. Job scan / Hypatia Neurosymbolic Analysis fails at
Set up job — no steps execute — with:

Unable to resolve action `github/codeql-action/upload-sarif@b96794f015dfd88f77b49b1c93e0fa7110f94c63`:
invalid lockfile pin. Run `gh actions-lock` to update the lockfile

selur calls hypatia-scan-reusable.yml@8ff9ce65f7e54f8d5c5aa94584e2ead0f2ba460f,
which is 5 commits after #1271 (compare f335165a…8ff9ce65 → ahead_by: 5, behind_by: 0). So this is not a caller lagging behind the fix; it is the leaf
#1271 did not reach, and the message names that leaf, exactly as #1271's own
rationale predicts.

A second, independent instance on metadatastician/lintel: scorecard.yml
(schedule, scorecard-reusable.yml, same codeql-action leaf) has concluded
startup_failure on three consecutive nightly runs — 38848566160
(2026-10-16), 39001087911 (2026-10-17), 39095716061 (2026-10-18). A
startup_failure run creates no job at all, so there is no job annotation to
quote for it; the attribution to the same leaf is by inspection of
scorecard-reusable.yml, not by measurement. Stated separately so the two
kinds of evidence are not confused.

Two more are latent rather than firing: mirror-reusable.yml's ssh-agent leaf
(lintel's mirror.yml jobs skip for want of mirror credentials) and
rust-ci-reusable.yml's setup-zig / rust-cache leaves (lintel has no
Cargo.toml, so those jobs skip — they are live in any Rust repository in the
estate).

Why no caller can fix this

The lock consulted for a reusable workflow's dependencies is the defining
repository's. A caller may pin the reusable to any commit it likes and record
whatever it likes in its own lock; the leaf resolution still happens against
this repository's actions.lock. There is no caller-side change that avoids it,
which is what makes this an estate-wide outage rather than a per-repo bug.

Remedy

Four ref: values, each measured to resolve to the pinned SHA (queried against
the upstream repositories' tags on 2026-10-18; all four are lightweight tags
pointing straight at the commit, so no tag-object peel is needed):

swatinem/rust-cache is also reachable as v2, but v2.9.2 is the precise tag
at that SHA and matches the convention #1271 used for the other nine. No
commit: value changes and no pin moves — the same discipline as #1271.

Acceptance criteria

1. The four ref: values above are corrected; commit: and every
   owner_id / repo_id are untouched.
2. The lockfile's own validator accepts the result.
3. A guard is added so a leaf entry whose ref: equals the 40-hex SHA in its
   own key cannot be committed again. ci(actions-lock): leaf entries need a tag ref, not the pin's own SHA #1271 was a manual sweep of nine of
   thirteen; the reason four survived is that nothing enforces the rule. A
   check over the lockfile that fails on ref == key's own SHA (excluding
   caller-side hyperpolymath/* self-entries, which legitimately use it)
   converts this from a recurring outage into a lint failure.
4. Re-measure on a post-fix pin in at least one caller and record the green.

Downstream workaround already in place

metadatastician/lintel has suspended its call to hypatia-scan-reusable.yml
(metadatastician/lintel#8) rather than leave a permanent red that reads as a
security failure. Its own Hypatia coverage is unaffected — the scanner still
runs inside static-analysis-gate.yml on every PR and push. The call returns
the moment this is fixed.