ci: re-pin codeql-action to the true v4.38.0 commit (#138)

## Re-pin `codeql-action` to the **true** v4.38.0 commit

This repo pinned `github/codeql-action` to a commit whose trailing
comment said `# v4.38.0`.
It is not v4.38.0. Dereferencing both annotated tags:

| tag | tag object | commit |
|---|---|---|
| `v4.38.0` | `4bd7200e` |
**`b96794f015dfd88f77b49b1c93e0fa7110f94c63`** |
| `v4.38.1` | `c23de5a8` | `1c5b675653bb5c22dbe9b12b556ec555138e09fd` |

So the pin was **v4.38.1** — the version blocked estate-wide
(nexia-list#100) — wearing a
`v4.38.0` label. The comment lied; in several repos the `actions.lock`
recorded
`ref: 'v4.38.1'` for the same SHA and had been telling the truth all
along.

Where the ref was a **bare tag** `@v4.38.1`, it was additionally
**unpinned** — a mutable ref
upstream can re-point at any time. Those are now pinned to a SHA *and*
moved off the blocked
version.

### Why one commit

GitHub compares `actions.lock` to the workflow **by literal string**. A
lock edit and a workflow
edit that disagree — even for one commit — produce a `startup_failure`,
not a stale lock. So the
workflow `uses:`, the lock's `workflows:` reference, the `dependencies:`
record
(`ref`, `commit`, key) and any nested `uses:` sub-list all move together
here.

### Several of these workflows are dead on `main` right now

A base-state census of all 40 affected repos compared each workflow's
literal `uses:` ref against
its own `actions.lock` entry **before** any change:

| lock state for the affected workflow | repos | status on `main` |
|---|---|---|
| no `actions.lock` at all | 14 | runs — workflow-only rewrite |
| entry **agrees** with the workflow | 19 instances | runs — lock and
workflow move together here |
| entry **already names `b96794f0…`** while the workflow still pins the
blocked SHA | 16 instances | **`startup_failure` — dead** |
| no entry for that workflow path | 2 instances | runs (enforcement is
per-path opt-in) |

That third row is the important one. In those repos the lock had
**already** been moved to the
correct v4.38.0 commit and the workflow never followed, so the two
disagree and GitHub rejects the
run at startup. Directly observed: `hyperpolymath/scripts` reports
`CodeQL Security Analysis
startup_failure` on its current `main` head.

So for those repos this PR is not hygiene — it **resurrects a CodeQL
workflow that has not run at
all**. Expect previously-absent checks to appear; a red among them is a
scanner speaking for the
first time, not a regression.

The last row was measured, not assumed: a *missing* lock entry leaves a
workflow unvalidated and it
runs normally (`metadatastician/metadatastician-governance`, whose lock
covers 3 of 8 workflows).
Only a *disagreeing* entry is fatal. No lock keys are added here —
adding one would newly **enable**
enforcement for a workflow that is currently exempt, which is a policy
change, not a repair.

### How this was verified before it was written

The transformer was dry-run against fetched copies of every distinct
shape in the estate and the
result checked **semantically at the YAML level**, not by reading a
diff:

- the `codeql-action` record reads exactly `ref: v4.38.0`, `commit:
sha1-b96794f0…`, with
  `owner_id`/`repo_id` untouched;
- every `workflows:` edge **and** every nested `uses:` edge resolves to
a record — the lock stays
**transitively closed**, which is what actually keeps jobs from
vanishing;
- no file anywhere still names the blocked version;
- a **line-conservation invariant** holds: every output line is an input
line, possibly retargeted.
A line may only be dropped as a rename-collapse duplicate, and every
drop is reported.

The dry run caught three destructive bugs before any repo was touched —
an over-eager dedupe that
deleted pre-existing legitimate refs, a record-body pattern that
silently dropped 12-space nested
`uses:` lists, and a line rebuild that ate the `- ` of list-item
`uses:`.

**Mutation-tested**, because a passing check proves nothing until it
kills a mutant: blinding the
workflow rewriter and blinding the lock retarget were both **caught** by
the cross-file lock guard;
the unmutated control reports `LOCK-OK`.

### Expected effect

CodeQL moves from the blocked v4.38.1 to v4.38.0. Any red here that
predates this commit is
pre-existing and is tracked separately under the stopping rule — a new
scanner finding is an issue
with acceptance criteria, not a merge blocker.

Refs metadatastician/standards#1005.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: hyperpolymath

.github/workflows/codeql.yml

@@ -43,12 +43,12 @@ jobs:
         uses: actions/checkout@v7.0.1
 
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4.38.0 (4.38.1 blocked estate-wide; nexia-list#100)
+        uses: github/codeql-action/init@b96794f015dfd88f77b49b1c93e0fa7110f94c63 # v4.38.0 (4.38.1 blocked estate-wide; nexia-list#100)
         with:
           languages: ${{ matrix.language }}
           build-mode: ${{ matrix.build-mode }}
 
       - name: Perform CodeQL Analysis
-        uses: github/codeql-action/analyze@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4.38.0 (4.38.1 blocked estate-wide; nexia-list#100)
+        uses: github/codeql-action/analyze@b96794f015dfd88f77b49b1c93e0fa7110f94c63 # v4.38.0 (4.38.1 blocked estate-wide; nexia-list#100)
         with:
           category: "/language:${{ matrix.language }}"