CI: converge the secret scan on the shared hseshadr/ci brick

[hseshadr]

Claim touched

"Every commit in this repo's full history is scanned for secrets on every PR."

This PR does not change whether that claim holds — it changes where the one
maintained copy of the control lives. The inlined gitleaks job was a
hand-maintained duplicate of the reusable workflow in hseshadr/ci, and it had
already drifted from it.

What changed

.github/workflows/ci.yml only. The inlined job is replaced by a SHA-pinned call
to the shared brick:

uses: hseshadr/ci/.github/workflows/secret-scan.yml@605e51cbc86f452b56edcf1c9660921da797cbfe # ci-v3.2.1

The SHA is the dereferenced commit of the annotated tag ci-v3.2.1
(refs/tags/ci-v3.2.1 -> tag object edbd737d -> commit 605e51cb), verified
against the GitHub API, not copied from a branch head. The comment names the
exact patch version, never a floating # ci-v3.

The brick strictly strengthens the control. It carries two things the inlined
copy was missing:

	inlined job (before)	shared brick (after)
fetch-depth: 0 (full history)	yes	yes
persist-credentials: false	no	yes
pull-requests: read	no	yes

pull-requests: read is load-bearing, not cosmetic: gitleaks-action lists a
PR's commits over the API on pull_request events, and without that scope it
403s "Resource not accessible by integration" before it scans anything. The
caller job declares the scope explicitly because the workflow-level
permissions: contents: read does not grant it.

⚠️ Owner action required BEFORE merge — branch protection

The reported check name changes. A reusable-workflow call reports as
<caller job name> / <callee job id>. The caller job is named Secret scan and
the callee job id in the brick is gitleaks, so:

before	after
gitleaks	Secret scan / gitleaks

Branch protection on main currently requires exactly:

gate, ts-gate, gitleaks

It must become:

gate, ts-gate, Secret scan / gitleaks

…and that change must land BEFORE this PR merges. If it doesn't, the required
gitleaks context stops being reported the moment this lands on main, and
every subsequent PR blocks forever waiting on a check that no longer exists.

This is an owner action. I have not touched branch protection and will not.

Knock-on: PR #23 will need a rebase

Open PR #23 (feat/ordinal-agreement-and-confusion-counts) is based on
pre-conversion main, so its head still produces the old bare gitleaks
context. Once protection swaps to Secret scan / gitleaks, #23 must be rebased
onto main to produce the new context — otherwise it will sit blocked on a
required check its branch cannot emit.

Evidence

claim	proof
SHA is the annotated tag's commit	git/ref/tags/ci-v3.2.1 -> tag edbd737d… -> git/tags/edbd737d -> commit 605e51cb…
callee job id is gitleaks	read from secret-scan.yml at that exact SHA
local gate green	uv run poe gate — 193 passed, 100% coverage (90% floor), 4.3s
no other file asserted the inlined shape	grep -rn -i gitleaks outside .github/ returns nothing

The pinning guard still holds, unmodified

tests/test_workflow_security.py asserts every uses: in this repo — explicitly
including first-party hseshadr/ci reusable workflows — resolves to a full
40-hex commit SHA. Its PINNED regex already accepts the
owner/repo/path/to/workflow.yml@<sha> form, so the new call is covered by the
existing guard with no test change. That is the point: the guard was written
against the property (immutable ref), not the shape of any one job, so converging
onto the brick did not require weakening it.

No non-workflow file needed changing.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.