ci: bump actions off deprecated Node 20

[yolabingo]

Summary

GitHub deprecated the Node 20 runtime for Actions on 2025-09-19 (https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/). Runs using actions/checkout@v4, astral-sh/setup-uv@v6, and aws-actions/configure-aws-credentials@v4 were emitting Node 20 deprecation warnings on every job. This bumps all pins of these three actions to the earliest available major that runs on Node 24, across every reusable workflow in .github/workflows/.

Pin changes

Action	Old	New	Files
actions/checkout	v4	v7 (v7.0.1)	claude-executor.yml, deployment-guard.yml (x2), codex-executor.yml, bedrock-generic-executor.yml, bedrock-harness-executor.yml, tests.yml (x2)
actions/checkout	SHA pin 8ade135a… (# v4.2.2)	SHA pin 3d3c42e5aac5ba805825da76410c181273ba90b1 (# v7.0.1)	autodoc-executor.yml
astral-sh/setup-uv	v6	v7	codex-executor.yml, bedrock-harness-executor.yml
aws-actions/configure-aws-credentials	v4	v6	claude-executor.yml, codex-executor.yml, bedrock-generic-executor.yml, bedrock-harness-executor.yml
aws-actions/configure-aws-credentials	SHA pin e3dd6a42… (# v4)	SHA pin e6de054238d6b7531b4efff3b6587d9aade6a06c (# v6.2.3)	autodoc-executor.yml

actions/checkout v5 and aws-actions/configure-aws-credentials v6 are the first majors of each that run on Node 24 (verified against each release's action.yml: checkout v4=node20, v5/v6/v7=node24; configure-aws-credentials v4/v5=node20, v6=node24). Pinned to the newest available major (v7 / v6) rather than the minimum, since both are already GA. astral-sh/setup-uv only publishes a floating major-version tag through v7 (no bare v8/v9/v10 tag exists), so v7 is both the newest Node-24 major and the newest floating tag available — matches the repo's existing floating-tag pinning style.

Breaking-change notes

• aws-actions/configure-aws-credentials v5.0.0 changed invalid-boolean input handling — not applicable here, since every call in this repo only passes role-to-assume and aws-region (both strings), no boolean inputs.
• astral-sh/setup-uv v7.0.0 removed the deprecated server-url input — not used anywhere in this repo (only enable-cache: true is passed).
• actions/checkout v7.0.0 blocks checking out a fork PR's head ref under pull_request_target/workflow_run events. These workflows are workflow_call reusable workflows, so the effective event context comes from the caller; if a consumer invokes them from a pull_request_target/workflow_run workflow against a fork PR, checkout behavior may differ from before. Worth a quick check against real callers if any exist.

🤖 Generated with Claude Code

[github-actions]

🤖 Bedrock Review — qwen.qwen3-next-80b-a3b

New Issues

• 🟡 Medium: .github/workflows/autodoc-executor.yml:73 — Version pinning changed from v4.2.2 to v7.0.1 of actions/checkout; assumption: v7 introduces breaking changes in behavior (e.g., fetch-depth default, token scope, or checkout ref resolution) that may affect PR context or file access. What to verify: Does actions/checkout@v7 still support fetch-depth: 1 for merge ref access in PRs as v4 did? Does it require token: ${{ secrets.GITHUB_TOKEN }} explicitly now?
• 🟡 Medium: .github/workflows/autodoc-executor.yml:77 — aws-actions/configure-aws-credentials@v4 → v6.2.3; assumption: v6 may require audience or role-session-name parameters not previously needed. What to verify: Does OIDC token audience validation still pass with unchanged role-to-assume and aws-region?
• 🟡 Medium: .github/workflows/bedrock-generic-executor.yml:99 — actions/checkout@v4 → v7; assumption: fetch-depth: 1 in v7 may not resolve the merge commit if the PR is not mergeable. What to verify: Does v7 still expose the merge ref (refs/pull/*/merge) as v4 did?
• 🟡 Medium: .github/workflows/bedrock-harness-executor.yml:153 — astral-sh/setup-uv@v6 → v7; assumption: setup-uv@v7 changes cache directory structure or environment variable behavior. What to verify: Does uv still find and use the cached dependencies identically after upgrade?
• 🟡 Medium: .github/workflows/deployment-guard.yml:179 — actions/checkout@v4 → v7 with fetch-depth: 0; assumption: v7 may not support fetch-depth: 0 for full repo access in some contexts. What to verify: Does v7 still allow full repo checkout with fetch-depth: 0 as v4 did?

Existing

• 🟡 Medium: .github/workflows/autodoc-executor.yml:73 — Prior finding: Version pinning is brittle; no version pinning in aws-actions/configure-aws-credentials — still present after change.
• 🟡 Medium: .github/workflows/bedrock-generic-executor.yml:99 — Prior finding: fetch-depth: 1 may not be sufficient for full PR context — still present after change.

Resolved

• ✅ .github/workflows/autodoc-executor.yml:73 — Version pinning was previously using commit SHA (8ade135...) — now pinned to v7.0.1, which is more maintainable. This resolves the prior risk of SHA drift.
• ✅ .github/workflows/bedrock-generic-executor.yml:99 — Previously used actions/checkout@v4 without explicit version — now pinned to v7, resolving lack of version stability.

---

_{Run: #33181285911 · tokens: in: 3096 · out: 1023 · total: 4119}

[semgrep-dotcms]

Semgrep found 14 github-actions-mutable-action-tag findings:

• .github/workflows/tests.yml
  • L17 - Triage
  • L27 - Triage
• .github/workflows/deployment-guard.yml
  • L179 - Triage
  • L269 - Triage
• .github/workflows/codex-executor.yml
  • L155 - Triage
  • L160 - Triage
  • L166 - Triage
• .github/workflows/claude-executor.yml
  • L120 - Triage
  • L126 - Triage
• .github/workflows/bedrock-harness-executor.yml
  • L153 - Triage
  • L160 - Triage
  • L166 - Triage
• .github/workflows/bedrock-generic-executor.yml
  • L99 - Triage
  • L104 - Triage

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608.

If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.