actions-lock gate is permanently red on main, and its remediation contradicts canon rule 10

[hyperpolymath]

Summary

Two faults in the actions-lock machinery, both live on main today.

1 — scripts/check-actions-lock-gate.sh fails the build on a warning-severity finding. Every finding it emits is "severity": "warning", yet the run sets "valid": false and exits 1 with ::error::. A gate whose only findings are warnings but which hard-fails has no way to express "noted, not blocking", so the severity field is decorative.

2 — a stale entry in EXPECTED_ABSENT that the validator's own staleness check disagrees with. The list's comment promises "an entry that stops being used is reported as stale, so it cannot rot either" — the mechanism fires, but the two sides disagree about whether the ref is still in use, so one of them is wrong.

Measured evidence

Gate, on a clean checkout of main:

$ bash scripts/check-actions-lock-gate.sh ; echo rc=$?
{
  "workflow": ".github/workflows/tailscale-connect-reusable.yml",
  "category": "sha-as-ref",
  "severity": "warning",
  "confidence": "high",
  "dependency": "tailscale/github-action@780049a30b6ff5c378a9e7b389d15ece7a204888",
  "detail": "pinned to a bare SHA without a symbolic ref — weakens supply-chain traceability",
  "remediation": "pin to a tag instead: https://github.com/tailscale/github-action/releases"
}
  "lockfile_version": "v0.0.2",
  "valid": false
::error::actions-lock gate: lockfile verification FAILED (exit 1).
rc=1

Note the remediation contradicts estate canon rule 10, which requires a full 40-hex SHA pin. "Pin to a tag instead" is the opposite of the rule the rest of the estate enforces — including validate-sha-pins.sh, which would reject a tag. Two gates in this repo are asking for incompatible things about the same line.

Validator, run from the pre-commit hook on the same tree:

[validate-actions-lock] WARNING: stale exception, no workflow uses
  denoland/setup-deno@22d081ff2d3a40755e97629de92e3bcbfa7cf2ed
  -- remove it from EXPECTED_ABSENT
[validate-actions-lock] ✅ 25 SHA-pinned ref(s) found among 25 lockfile keys, 1 doctrine exception(s)

EXPECTED_ABSENT is at .githooks/validate-actions-lock.sh:70.

Acceptance criteria

• Decide and document whether sha-as-ref blocks or advises. If it advises, a warning-only run sets "valid": true and exits 0; if it blocks, its severity is raised to error so the JSON stops contradicting the exit code.
• The sha-as-ref remediation text is reconciled with canon rule 10 — a bare 40-hex pin is the estate requirement, so either the remediation changes to "add a # vX.Y.Z comment alongside the pin", or the conflict with validate-sha-pins.sh is stated explicitly and one gate yields.
• The denoland/setup-deno disagreement is resolved by measurement: either the ref is genuinely unused and the EXPECTED_ABSENT entry is deleted, or it is still referenced and the staleness check is fixed to see it. State which, with the command.
• scripts/check-actions-lock-gate.sh exits 0 on a clean main, or its failure is a tracked, ledgered exemption rather than permanent red.

Neither fault is a regression from #899 or #931 — both were measured on main before and after. Found while measuring #931.

[hyperpolymath]

Two corrections to the body above, both measured after filing — they sharpen the finding rather than change it.

1 — the warning count is 94, not "the findings shown".

$ bash scripts/check-actions-lock-gate.sh 2>&1 | grep -o '"severity": "[a-z]*"' | sort | uniq -c
     94 "severity": "warning"

Every one of 94 findings is warning. There is not a single error among them, and the gate still sets "valid": false and exits 1. So the severity field is not merely decorative in one case — it is unused across the entire output, and the gate is red on main for 94 advisory items.

2 — the denoland/setup-deno entry is not merely "stale", it is self-contradictory.

EXPECTED_ABSENT is documented as "refs deliberately absent from the lockfile". That ref is in the lockfile:

$ grep -rn 'denoland/setup-deno' .github/workflows/
.github/workflows/governance-reusable.yml:376:   # `denoland/setup-deno` install onto a REQUIRED context in every   <- a comment
.github/workflows/actions.lock:64:      - 'denoland/setup-deno@22d081ff2d3a40755e97629de92e3bcbfa7cf2ed'
.github/workflows/actions.lock:212:   'denoland/setup-deno@22d081ff2d3a40755e97629de92e3bcbfa7cf2ed':

So both sides are right about different questions, which is why they disagree:

• the validator asks "does any workflow uses: this ref?" — no (line 376 is a comment), so it reports the exception stale;
• the list asks "is this ref absent from the lockfile?" — also no, it is a key at line 212.

The entry therefore claims an absence that is not true, about a ref that is not used. This is the estate's recurring guard-asks-a-different-question-than-its-consumer shape again, the third instance found in this sweep.

Revised acceptance criterion, replacing the third checkbox above:

• Remove the denoland/setup-deno entry from EXPECTED_ABSENT and decide whether its actions.lock keys at lines 64 and 212 should go with it, given estate doctrine is bun-only and no workflow references it. State the decision; do not leave a banned runtime as a live lockfile key by default.