Name the exact version in a pin comment rather than the major

[iderex]

Closes #137

What this changes

Two steps in .github/workflows/codeql.yml pinned a commit and commented it
# v4. The comment now names # v4.37.6, which is the exact version the pinned
commit is tagged as. The commit itself is unchanged, so nothing new is run:

$ gh api repos/github/codeql-action/git/ref/tags/v4.37.6 --jq '.object.sha'
9e3211c9a3b9311dfe05da2ed48eea3386f042dd
$ gh api repos/github/codeql-action/git/tags/9e3211c9a3b9311dfe05da2ed48eea3386f042dd --jq '.object.sha'
5595ccaf912efad79be6eef63a5619ff05969be3

That is the first of the three ways out the issue lists, and it is the one that
takes no version this board's gate has not already walked. v4 today points
somewhere else, and that somewhere else is a release published after the last
green run on the default branch:

$ gh api repos/github/codeql-action/git/ref/tags/v4 --jq '.object.sha'
988661ebb5e81487b3fb31b2185d2856c0a10679
$ gh api repos/github/codeql-action/git/tags/988661ebb5e81487b3fb31b2185d2856c0a10679 --jq '.object.sha'
ff2f1c621b7f889edc0d3c761ac2e6a3f8cdb0dd
$ gh api repos/github/codeql-action/releases/tags/v4.37.7 --jq '.published_at'
2026-08-13T13:30:27Z

The spelling this repository uses is written at the two places a reader of those
steps opens. The header of codeql.yml says why the comment names an exact
version and hands over the command that finds a bare major anywhere in the tree.
The rule block in zizmor.yml, which is where a future workflow change is told
what to keep, now names the spelling next to the other four things it already
names.

That block also listed a pin-comment mismatch among the low-severity hygiene
findings the pedantic persona adds and this gate deliberately does not act on.
That was wrong. It is corrected where it stood, and it rides in this change
rather than a separate one because the sentence sits four lines above the rule
this change edits.

What failure it prevents

A check that is red on everything and blocks nothing. The audit is outside the
required set on this board:

$ gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
pull_request

So the permanent red refused no merge, and what it cost instead was a column
people stop reading. The next finding the audit reports would have arrived
there.

The narrower failure is the comment itself. A comment naming a moving reference
is a claim that goes stale on somebody else's schedule, with no change here,
which is what happened. Every zizmor run this board recorded before the tag
moved concluded success, and both runs recorded after it concluded failure:

$ gh api "repos/Flowfin/lab/actions/workflows/zizmor.yml/runs?per_page=15" \
    --jq '.workflow_runs[] | "\(.id) \(.event) \(.conclusion) \(.created_at)"'
31968878147 pull_request failure 2026-08-16T19:52:36Z
31929377858 pull_request failure 2026-08-16T05:35:50Z
31698607881 push success 2026-08-13T12:07:49Z
31698475674 pull_request success 2026-08-13T12:06:04Z
31677996685 push success 2026-08-13T07:29:53Z

An exact version is a claim about the commit written beside it, and that cannot
move.

Every other pin in this tree already named an exact version, so this is two
outliers joining the rest rather than a convention being introduced. Counted on
the parent of this change:

$ git grep -cE 'uses: .*@[0-9a-f]{40} # ' -- .github/workflows/ | awk -F: '{s+=$2} END {print s}'
35
$ git grep -cE 'uses: .*@[0-9a-f]{40} # v[0-9]+$' -- .github/workflows/ | awk -F: '{s+=$2} END {print s+0}'
2

What was run

The audit that reports this runs on GitHub and not on this machine, so the
before and after are two runs of the same job rather than a local reproduction.

Before, on the head of #136, which touches no workflow file:

$ gh run view 31968878147 --repo Flowfin/lab --log-failed
warning[ref-version-mismatch]: action's hash pin has mismatched or missing version comment
  --> ./.github/workflows/codeql.yml:71:84
   |
71 |         uses: github/codeql-action/init@5595ccaf912efad79be6eef63a5619ff05969be3 # v4
   |                                                                                   ^^ points to commit ff2f1c621b7f
   |         is pointed to by tag v4.37.6
   |
   = note: audit confidence -> High
warning[ref-version-mismatch]: action's hash pin has mismatched or missing version comment
  --> ./.github/workflows/codeql.yml:89:87
4 findings (2 suppressed, 2 unsafe fixes): 0 informational, 0 low, 2 medium, 0 high
##[error]Process completed with exit code 13.

That red is what shows the audit bites for the reason it names, and it bit at
those two sites and at no other, on a change that contained neither of them.

After, on this head, the same job over the same fourteen files:

$ gh run view 31971449772 --repo Flowfin/lab --log
INFO audit: zizmor: completed ./.github/workflows/scorecard.yml
INFO audit: zizmor: completed ./.github/workflows/unicode-guard.yml
INFO audit: zizmor: completed ./.github/workflows/zizmor.yml
No findings to report. Good job! (2 suppressed)

The suppressed pair is unchanged across both runs, so what moved is the two
medium findings and nothing else. Every other check on this head is green:

$ gh pr checks 138 --repo Flowfin/lab

Locally, at the head of this branch:

$ go vet ./...
$ go test ./... -count=1
ok  	github.com/Flowfin/lab/cmd/contexts	0.499s
ok  	github.com/Flowfin/lab/cmd/lab	1.696s
ok  	github.com/Flowfin/lab/cmd/notices	5.183s
ok  	github.com/Flowfin/lab/cmd/pullrequest	0.512s
?   	github.com/Flowfin/lab/experiments/reading-a-tree-of-records	[no test files]
ok  	github.com/Flowfin/lab/internal/check	0.851s
ok  	github.com/Flowfin/lab/internal/contexts	0.499s
ok  	github.com/Flowfin/lab/internal/hardware	0.533s
ok  	github.com/Flowfin/lab/internal/invariants	0.809s
ok  	github.com/Flowfin/lab/internal/notices	0.525s
ok  	github.com/Flowfin/lab/internal/prose	0.511s
ok  	github.com/Flowfin/lab/internal/pullrequest	0.549s
$ go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
18 decision records read
0 refused

zizmor was not run on this machine. uvx, uv and zizmor are all absent
here, and the gate installs it from a wheel at run time, so the verdict that
counts is the job's.

Nobody but me has read this change. There is no second reader on this board
tonight, and the evidence above stands in place of one rather than alongside
one.

What this does not do

It does not move a pin. github/codeql-action runs at the same commit after
this change as before it, so nothing here is a statement about v4.37.7, and
whether to take that is the update tool's to raise.

It does not add a check. What refuses a wrong pin comment is the audit, which
already did, and this change makes it stop refusing rather than giving it a
second reader in this tree. Nothing in this tree reads a pin comment.

It does not put the audit in the required set. That stays where issue #26 holds
it, and the issue says why a board-wide red becoming a board-wide block would
not have been a repair.

It does not silence anything. There is no suppression and no ignore comment,
and the audit still reports these two sites if the comment and the commit ever
disagree again.