Restore the reason a pin comment names the exact version (#155)

[iderex]

Refs #155

What this changes

Comments in .github/workflows/codeql.yml and .github/workflows/zizmor.yml,
and nothing else. No line outside a comment moves in either file:

git diff origin/main -U0 | grep -E '^[+-]' | grep -vE '^(\+\+\+|---)' | grep -vE '^[+-]#' ; echo "exit=$?"
exit=1

Sixteen lines come back in codeql.yml, saying why the version in a pin comment
is the exact one the pinned commit is tagged as rather than the major. Both
spellings leave the same commit running, so the whole difference is what the
comment claims: a comment naming a major is a claim about a reference upstream
moves and stops being true on the day upstream tags a release, while an exact
version is a claim about the commit written beside it and cannot go stale on its
own. That file is the bytes that were there rather than a retyping of them:

git rev-parse 90656ba:.github/workflows/codeql.yml
ea3a07e8b0c43135d70a446cedca1505cb745a8a
git hash-object .github/workflows/codeql.yml
ea3a07e8b0c43135d70a446cedca1505cb745a8a

In zizmor.yml only the comment goes back and the pin stays where it moved to,
which is what #155 asks for on this file. The header had returned to listing a
pin comment that disagrees with its commit among the pedantic hygiene findings
the gate does not collect, and the paragraph saying that reading is wrong, plus
the clause in the rule sentence asking for the exact version, come back with it.

The means is a comment in the file the rule governs, which adds no format, no
tool and no second place to look.

How the absence arrived

d3edfc95b8526033c79cb26afe48282c2c090e32 took its tree from an older state of
the default branch and landed on top of a newer one, under a message describing
a change to how one workflow pin is commented. Both files were among the seven
paths it replaced, and it is the only commit to have touched either since:

git log --format='%H %s' 90656ba..origin/main -- .github/workflows/codeql.yml .github/workflows/zizmor.yml
d3edfc95b8526033c79cb26afe48282c2c090e32 Name the version the pinned commit actually is (#151)

So the change kept the state and dropped the argument for it. The pins on the
default branch already name exact versions and are untouched here.

What failure it prevents

The next edit spelling a pin comment as a major because neither file says why
not, and a reader taking the pedantic list in zizmor.yml for the complete set
of what the gate lets through. A pin comment that disagrees with its commit is
not in that set: the regular persona reports it at medium and the gate runs at
--min-severity=low, so the step below it fails the build on one.

Both facts the restored text rests on were re-read rather than trusted. No pin
comment anywhere in this tree names a major:

git grep -nE 'uses: .*@[0-9a-f]{40} # v[0-9]+$' -- .github/workflows/ ; echo "exit=$?"
exit=1

and the step the sentence points at is present:

grep -n 'Fail on actionable findings' .github/workflows/zizmor.yml
82:        # skip the "Fail on actionable findings" step below.
90:      - name: Fail on actionable findings

Nothing in this tree refuses a pin comment naming a major on its own. What
refuses one is the audit job, which is a check on this board rather than a
property of the tree, and these comments are the reason written where the next
editor will meet it. They are prose beside a check, not a check.

What was run

At fa0816c3da92073b172a09ae917b5d5943d85e7e, on Windows, with no graphical
session and as an ordinary user:

go build ./cmd/... ./internal/...
go vet ./cmd/... ./internal/...
gofmt -l cmd internal
go test -count=1 ./cmd/... ./internal/...
ok  	github.com/Flowfin/lab/cmd/contexts	0.461s
ok  	github.com/Flowfin/lab/cmd/lab	1.298s
ok  	github.com/Flowfin/lab/cmd/notices	8.226s
ok  	github.com/Flowfin/lab/cmd/pullrequest	0.484s
ok  	github.com/Flowfin/lab/internal/check	0.714s
ok  	github.com/Flowfin/lab/internal/contexts	0.454s
ok  	github.com/Flowfin/lab/internal/hardware	0.491s
ok  	github.com/Flowfin/lab/internal/invariants	0.730s
ok  	github.com/Flowfin/lab/internal/notices	0.452s
ok  	github.com/Flowfin/lab/internal/prose	0.483s
ok  	github.com/Flowfin/lab/internal/pullrequest	0.456s

go build, go vet and gofmt -l each printed nothing, which is the passing
result for all three.

go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
18 decision records read
the time this run read is 2026-08-21T14:00:16Z
0 refused

The suite is untouched by this change, so a green run here is evidence that
nothing broke rather than evidence that the comments are right. What judges the
workflow files is the audit job on this pull request.

No test was skipped for needing elevation, and none was run with any.

What this does not do

It does not finish #155. Three path groups that commit removed are still
missing: LICENSE with the ## License section of README.md, two sections of
docs/quality-parity.md, and fifteen lines of docs/operator-guide.md.

It does not touch the second question #155 raises, which is whether anything
here should refuse a merge that removes a tracked path without saying so in its
body.

It does not move any pin, and it does not move #26 or #151. The state both of
those landed is already on the default branch; what was missing is the reason.

No second person has read this change. The evidence above stands in place of
one, and that is a disclosure rather than an assurance.