ci: collapse the checkout and nix-installer pins to one version each

[bdelanghe]

Pinning by SHA makes a pin immutable; it doesn't make it consistent. These workflows had drifted into four different actions/checkout pins and two nix-installer-action pins across nine files — the same fact recorded in several places, each updated on its own schedule.

What changed

Action	Was	Now
actions/checkout	34e1148 (v4) ×3, 08c6903 (v5) ×2, df4cb1c (v6.0.3) ×1, 9c091bb (v7.0.0) ×10	3d3c42e (v7.0.1) ×16
DeterminateSystems/nix-installer-action	90bb610 (v19) ×2, 1d87d45 (v20) ×1	ef8a148 (v22) ×3

19 lines, 9 files. No other change.

Why these targets

v7.0.1 is both the current checkout release and the version most of these workflows were already on — 10 of 16 call sites. This moves the remaining six up to meet them rather than introducing a new standard.

Risk

checkout v7.0.0's only behavioural change is that fork PRs are no longer checked out under pull_request_target or workflow_run.

• The four workflows actually upgrading a major here — org-defaults.yml, registry-graph.yml, seam-coverage.yml, site-deploy.yml — none use either trigger.
• The first three are repo-internal (push / pull_request / schedule / workflow_dispatch), so their exposure is zero.
• site-deploy.yml is workflow_call, so the caller's event decides. That's the one call site whose consumers this repo can't enumerate — flagging it rather than claiming it's clear. A caller would have to invoke a production-deploy workflow from pull_request_target/workflow_run to be affected.

nix-installer v22 still accepts extra-conf, the only input any of these call sites passes; the two in site-deploy.yml pass no inputs at all.

Verification

• All 12 workflows parse (yaml.safe_load).
• Every uses: is still pinned to a 40-hex SHA — no tag refs reintroduced.
• Every target SHA confirmed against git ls-remote on the upstream repo. Worth noting: checkout's v6.0.3 tag is annotated, so the correct pin is the dereferenced commit df4cb1c, not the tag object 9f69817 — whoever pinned it originally got that right. The new v7.0.1 tag is lightweight, so its SHA is the commit directly.

Downstream

Consumers tracking main pick this up on merge. bounded-systems/site pins site-deploy.yml by SHA, so it needs a separate follow-up bump to this merge commit before it sees the change — that repo is outside this session's scope, so it isn't included here.

---

Generated by Claude Code

[bdelanghe]

CI status: 15/16 green. The one red — coverage — is pre-existing on main and not caused by this diff.

I ran a control: dispatched seam-coverage.yml on main (run 30600571408), where the pin is still checkout v6.0.3. It fails at the same step as the PR run:

	PR (c693d07)	main (3bb0154)
Checkout	✅ success	✅ success
Setup Bun / Install	✅ success	✅ success
Seam coverage step	❌ failure	❌ failure

Same step, same conclusion, with Checkout green in both. The pin bump isn't the cause.

What is: check-seam-coverage.ts enumerates the org's public repos, keeps the ones whose package.json carries a bounded block, clones each, and asserts every one declares a seam claim. That makes it a check on org state, not on this repo's contents — it goes red when a new capability repo appears without a seam claim, with no commit here. It was green on main as recently as 2026-07-28, so something crossed that line since.

I'm not fixing it in this PR. The fix is either a seam claim in whichever repo is newly uncovered, or an EXEMPT entry with a written reason — both outside a pin consolidation, and the target repo is outside this session's scope, so I can't confirm which repo it is or read it. The step's own error message names the offending packages; that output will identify it.

Worth noting separately: Analyze (actions) (CodeQL over the workflow files) passed on this diff.

---

Generated by Claude Code