ci: pin remaining GitHub Actions to commit SHAs

[0xrlawrence]

Summary

ci.yml referenced three actions by mutable tag, while release-binaries.yaml already pins the same actions by commit SHA. This brings ci.yml in line with that existing convention.

Action	Uses	Now pinned to
actions-rust-lang/setup-rust-toolchain@v1	5	166cdcfd… (v1.17.0)
taiki-e/install-action@v2	2	a2a5f6e9… (v2.86.4)
foundry-rs/foundry-toolchain@v1	4	908c5403… (v1.9.1)

Why

A mutable tag can be force-moved, and a compromised upstream action would execute arbitrary code in CI. SHA pinning makes the supply chain immutable. This is the practice release-binaries.yaml already follows:

uses: actions-rust-lang/setup-rust-toolchain@150fca883cd4034361b621bd4e6a9d34e5143606 # v1.15.4

Behaviour

Unchanged. Each SHA is the commit that the corresponding @v1 / @v2 tag currently resolves to, so CI runs exactly the same action versions as before. The # vX.Y.Z trailing comments follow the existing convention so future bumps stay readable.

Noticed while doing a general review of the repository.

🤖 Generated with Claude Code

[osr21]

Verified the three SHA↔tag mappings independently against the upstream repos — all correct:

Pinned SHA	Resolves in upstream repo to	Matches claim
166cdcfd…	actions-rust-lang/setup-rust-toolchain tag v1.17.0	✅
a2a5f6e9…	taiki-e/install-action tag v2.86.4	✅
908c5403…	foundry-rs/foundry-toolchain tag v1.9.1	✅

Each SHA is the real tagged commit in the genuine upstream repository (not a fork), so there's no impersonation risk in the pins themselves.

Coverage check: I scanned every uses: line across all five workflow files at this PR's head — after this change there are zero remaining mutable-tag references to third-party actions in the repo (build-docker.yaml, finalize-release.yaml, label-external-prs.yml, and release-binaries.yaml were already fully pinned). So the title's "remaining" is accurate: this completes repo-wide SHA pinning.

One nuance on the "Behaviour: unchanged" claim: it holds exactly for two of the three — the floating v1 tags of setup-rust-toolchain and foundry-toolchain still resolve to the same commits being pinned. But taiki-e/install-action@v2 has already moved ahead (it now resolves to 37f7c578…, newer than the pinned v2.86.4) — that project cuts releases almost daily. So merging this pins CI slightly behind what @v2 would fetch today. That's not a defect — freezing that drift is exactly the point of the PR — but "runs exactly the same action versions as before" is only true relative to when the PR was authored, and reviewers shouldn't be surprised when a future bump of this pin jumps many patch versions.

Two adjacent observations, in case maintainers want follow-ups (fine to keep out of this PR's scope):

1. release-binaries.yaml now diverges from ci.yml on shared actions: it pins setup-rust-toolchain at 150fca88… (v1.15.4, two minors behind this PR's v1.17.0) and pins taiki-e/install-action at a661f9d0…, which its own comment flags as an untagged 2025-07-01 commit. Untagged pins are the hardest to audit (no release notes to diff against); moving it to the nearest tagged release and harmonizing versions across the two workflows would be a natural next step.
2. Worth pairing SHA pins with an update bot (Dependabot package-ecosystem: "github-actions" or Renovate) so they don't go stale silently — both handle SHA pins natively and rewrite the trailing # vX.Y.Z comment on bump.

LGTM — small, mechanical, verifiable line-by-line, and consistent with the StepSecurity checks the repo already enforces (SHA pinning is their top recommendation).