Harden CI: pin sync-github-about's actions and drop the job credential

[vivekchand]

Product record: No-PRD: CI-only change; .github/ is exempt per scripts/check_product_record.py.

Risk: None to product code. The workflow keeps the same trigger, steps and outputs — only the action refs and one checkout input change. If actions/checkout@v7.0.1 or actions/setup-python@v7.0.0 misbehaved here, the blast radius is the About blurb not syncing; every other workflow in the repo already runs these exact SHAs. Undone by reverting one commit.

Summary

• sync-github-about.yml landed on main earlier today (Make SUPPORTED_RUNTIMES.txt the one runtime list every surface derives from #5762) with actions/checkout@v4 and actions/setup-python@v5. Those were the only two unpinned uses: references left in the repository — the other 65 checkout and 52 setup-python references are already pinned to a commit SHA. This puts them back on the same pins.
• A floating tag is mutable: the repository that owns @v4 can repoint it at new code, which then runs inside our job. Pinning is what the repo standardised on across Harden CI: pin the remaining third-party actions to commit SHAs #5285 / Harden CI: pin the remaining first-party actions to commit SHAs #5294; a single convenient tag in a later PR is how a slice of it comes undone.
• The checkout also now sets persist-credentials: false. This job never pushes with the job credential — it reads the tree and writes the About blurb through the API with REPO_ADMIN_TOKEN — so leaving GITHUB_TOKEN in .git/config handed it to every later step for no reason. 60 of the repo's 67 checkouts already set this; the seven that do not are the workflows that genuinely push with the job credential (release-on-merge, the i18n autotranslate pair, auto-quarantine, auto-deploy-cloud), which this is not.

Same actions, same steps, same trigger — no behaviour change.

Why the pins are these SHAs

Not newly chosen: 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 and 5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0 are the pins every other workflow in this repo already uses, and supply-chain.yml resolves them live against the GitHub API on each run (CLAWMETRY_LIVE_CHECKS=1). Reusing them keeps one version of each action across the repo rather than introducing a second.

Interaction with #5305

#5305 adds the ratchet that keeps pinning done (tests/test_action_refs_pinned.py, wired into ci.yml). That branch predates this workflow and does not contain it, so the two refs here would have taken the new test red on merge. This clears them; the two changes are complementary, and neither depends on the other landing first.

Test plan

• Every workflow parses: python3 -c "import yaml,glob; [yaml.safe_load(open(f)) for f in glob.glob('.github/workflows/*.yml')]" — clean
• python3 -m pytest tests/test_workflow_yaml_valid.py -q — 550 passed, 340 skipped
• Repo-wide sweep for unpinned uses: across .github/workflows/*.yml and .github/actions/**/action.yml — 0 remaining (was 2, both in this file)
• persist-credentials audit re-run: 67 checkout references, 61 now set it; the 6 without are exactly the credential-pushing workflows listed above

🤖 Generated with Claude Code

https://claude.ai/code/session_016s3JTqS53GE2oNVdv98rN5

---

Generated by Claude Code

[8090-software-factory]

✅ Drift Bot (ClawMetry): no drift detected

Drift Bot analyzed the changed files against this project's blueprints and requirements and found no drift.