ci: consolidate action pins — one SHA per action, no moving tags

[noahgift]

The fleet asks GitHub for six different actions/checkout refs, and each is a separate cache entry on each of 16 runners. Measured 2026-08-17:

ref	resolves to	uses
@v7 (tag)	v7.0.1	31
@df4cb1c0…	v6.0.3	20
@de0fac2e…	v6.0.2	13
@v6, @v5 (tags)		4
@34e11487… ← this file	v4.3.1	6

16 runners × 6 refs ≈ 96 downloads of one action, which is why CI spent the afternoon failing on:

Failed to download action 'https://codeload.github.com/actions/checkout/tar.gz/...'
429 (Too Many Requests) ... after 3 attempts

This is not an API rate limit

gh api rate_limit read core 106/5000, graphql 0/5000 while it was happening. codeload.github.com is a different endpoint with no published limit — so "we're inside our documented budget" and "we're being 429'd" are both true simultaneously, and nothing in rate_limit will ever show it. The amplification is ours.

Why this file first

Every repo consumes it, and it was pinning the oldest checkout in the fleet — v4.3.1, three majors behind everything else.

actions/checkout         34e11487 (v4.3.1)  ->  3d3c42e5 (v7.0.1)
actions/upload-artifact  @v4 (moving tag)   ->  ea165f8d (v4.6.2)

v7.0.1 is not a leap into the unknown: 31 uses across the fleet already run @v7, which resolves to exactly this commit today and passes. For those it becomes a no-op that removes a moving tag; for this file it is the upgrade it had been missing.

Supply chain, not just bandwidth

No moving tags remain in this workflow. A moved tag is both a re-download and an unaudited change.

Follow-up

Per-repo pins still need consolidating onto the same SHA — mechanical, sequenced after the open dependabot bumps rather than colliding with them.

A shared runner-level cache (ACTIONS_RUNNER_ACTION_ARCHIVE_CACHE, confirmed present in runner 2.336.0) would remove the 16× multiplier too, but its seeding convention isn't recoverable from the binary and needs an empirical test first.

🤖 Generated with Claude Code

[noahgift]

Heads-up from paiml/infra's nightly shared-cargo-home-guard — this branch is
flagged BLOCK, and it is a staleness artefact rather than something this PR did:

cargo-install-boot-volatile BLOCK .github#49/sovereign-ci.yml
  job=security step=Install_cargo-audit_(per-runner_CARGO_HOME)
  :: install root is emptied at boot: /tmp/cargo-home-security-RUNNER

This branch: CARGO_HOME="/tmp/cargo-home-security-${{ runner.name }}"
main: CARGO_HOME="$RUNNER_TOOL_CACHE/cargo-home-security"

/tmp is emptied at boot, so cargo-audit reinstalls on every fleet reboot;
$RUNNER_TOOL_CACHE persists. main already carries the better form — this
branch is 17 commits behind and predates that change.

No action needed beyond merging/rebasing main before this lands. Flagging it
because the guard scans open PR heads, not just default branches (a PR
migrating jobs onto the fleet is precisely how the fleet has been broken
before), so it will keep reporting until the branch catches up — and because if
this merged as-is it would reintroduce the regression on main.

Not pushing to your branch. Found while getting infra's nightly audit green
after 43 days red (paiml/infra#489).