ci: move every first-party action off the Node 20 runtime

[FrameAutomata]

Part 1 of #326. Bumps the 63 actions/* pins across all 16 workflows. Part 2 (ci/326-node24-third-party) handles the six third-party actions on the release workflows and is stacked on this branch.

GitHub currently reports this as a run annotation:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24

The forcing is the step before removal, and when that lands every workflow breaks at once — release-traceway.yml and release-cli.yml included. Losing the ability to cut a release is a bad way to find out.

Action		Uses
actions/checkout	v4 → v7	25
actions/setup-go	v5 → v7	15
actions/upload-artifact	v4 → v7	10
actions/download-artifact	v4 → v8	5
actions/setup-node	v4 → v7	4
actions/cache	v4 → v6	4

runs.using was read at each source and target ref: all six were node20, all six are now node24.

The three jumps with real behaviour changes

Not a sed 's/@v4/@v7/' — these skip 2–3 majors. Each was checked against how this repo actually calls it.

setup-go v6 changed toolchain handling (#460), and this repo cares: CLAUDE.md documents keeping go and toolchain in go.mod distinct. v6 installs the toolchain version rather than the go line's, and sets GOTOOLCHAIN=local so Go does not download one itself.

Both modules pin go 1.26.2 / toolchain go1.26.6, so the same compiler runs either way — v5 got there by downloading 1.26.6 on first use, v7 installs it directly. Same version, one less download.

GOTOOLCHAIN=local does mean a job that installs an older Go than a module's floor now errors instead of silently upgrading. One job installs an older Go: benchmark-hardware.yml (go-version: '1.25'). It only builds benchmarks/loadgen, which declares go 1.25; the backend there is built by docker compose --build on the Hetzner SUT, not by the runner's Go. So nothing regresses.

backend-vulncheck.yml documented the v5 mechanism in a comment — rewritten in this PR, since it would otherwise now be false.

setup-node v5 auto-enables caching when package.json has a packageManager field. No package.json in this repo has one, and three of the four call sites already set cache: "npm" explicitly.

download-artifact v5 changed output paths for single downloads by ID. Nothing here downloads by ID — every call site uses name:, or pattern: + merge-multiple: true, or downloads everything. v8 additionally errors rather than warns on a digest mismatch, which is the behaviour you'd want on a release artifact anyway.

upload-artifact v7's archive: false is opt-in with the default unchanged, and cache v5/v6 are runtime + ESM only — the key/restore semantics I'd expected to change didn't.

Runner requirement

These releases require Actions Runner ≥ 2.327.1. Every job here is ubuntu-latest or ubuntu-24.04 — all GitHub-hosted, no self-hosted runners — so that's already met.

Validating

backend.yml, backend-vulncheck.yml, cli.yml, cli-lint.yml and cli-contract.yml all run on the ci label, which exercises checkout, setup-go and cache — including the setup-go toolchain change, which is the one worth actually watching. The benchmark workflows (upload-artifact/download-artifact) are workflow_dispatch-only and cost real money to run, so those two are argued from the changelogs and the call sites above rather than from a green run.

Note for #315

frontend.yml, incoming via #315, adds actions/checkout@v4 and actions/setup-node@v4. Worth bumping those to @v7 there so it doesn't land already stale — this PR can't reach that file.

🤖 Generated with Claude Code

Also: one docs recipe

docs/pages/client/js-sdk/sourcemap-upload.mdx ships a copy-paste GitHub Actions recipe pinning checkout@v4 and setup-node@v4 — a reader following it lands on the same annotation. Bumped to @v7 in a separate commit.

Left alone deliberately: the node-version: 20 on the next line of that snippet (a question about what Node the JS SDK supports, not about the action runtime), and website/content/blog/auto-fix-loop.mdx, which pins upload-artifact@v4 in a published, dated post.

From a cleanup pass over this diff

backend.yml's Go caches would have carried a dead toolchain forever. Those three jobs set cache: false on setup-go and hand-roll actions/cache over ~/.cache/go-build and ~/go/pkg/mod, keyed on go.sum with a ${{ github.run_id }} suffix — so every run saves a fresh entry and the restore-keys carry the previous tree forward.

Neither cached tree survives a Go version change. go-build entries are compiler-keyed, and until this branch GOTOOLCHAIN=auto materialised a ~250MB golang.org/toolchain@...go1.26.6 module inside GOMODCACHE. setup-go v7 never writes that module again — but nothing deletes it either, and the module cache has no trimming, so the run_id rotation would have copied a dead toolchain forward on every run indefinitely.

Fixed by putting the resolved Go version in the key (steps.setup-go.outputs.go-version, with id: setup-go added to the three steps) rather than by a cleanup step. That fixes it for every future Go bump instead of this one — the cache generation now rotates whenever the compiler does. Costs one cold run per job, most of which was dead weight anyway.

The vulncheck comment rewrite got tightened. The first version named GOTOOLCHAIN=local for both setup-go and the golang Docker bases while asserting the two behave differently, which destroyed the contrast the comment exists to draw — the real difference is which Go gets installed first. The setup-go half no longer mentions the variable, and the Docker half now says explicitly that it ignores the toolchain line. The parenthetical recording v5's old behaviour is gone: no file pins setup-go@v5 any more, and git blame is the right home for a version delta.

Follow-ups filed

• Nothing detects GitHub Actions pin drift; the node20 sweep was found by accident twice in one day #330 — nothing in this repo detects action pin drift (no dependabot, no renovate, no pin check). Worth reading before closing Every workflow pins Node 20-based actions that GitHub is force-migrating to Node 24 #326: adopting Dependabot here is complicated by the label-gated CI, and half these pins sit on workflows no label reaches.
• wranglerVersion is pinned to 3 in three release workflows with no owner but a code comment #331 — tracks unpinning Wrangler (see ci: move the release-path actions off the Node 20 runtime #329).