Harden CI: pin gate/guard/quarantine workflow actions to commit SHAs

[vivekchand]

What

Continues the PinnedDependencies batches (after ci.yml #5275, supply-chain.yml #5276, the conformance/install/handoff set #5279, and the release pipeline #5281) with the nine PR-gate, guard and quarantine workflows. 17 refs, all 1:1 replacements of a floating major tag with the full commit SHA plus a version comment.

action	pinned to
actions/checkout@v7	3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
actions/setup-python@v7	5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
actions/setup-node@v7	820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
actions/upload-artifact@v7	043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1

Files: apply-required-checks.yml, c6-pr-gate.yml, c6-schedule-heal.yml, e2e-gate.yml, product-record-gate.yml, auth-bootstrap-guard.yml, auto-quarantine.yml, quarantine-sweep.yml, harness-observability-audit.yml.

Why

A floating tag is mutable. Whoever controls the upstream repository can repoint @v7 at a different commit, and the next run of these workflows fetches that commit with no change landing here and nothing to review. That is the Scorecard PinnedDependencies class.

These nine are worth doing as one batch because of what they are: they gate the merge queue, so they run against pull requests the repository does not control. A workflow that decides whether other changes may merge is a poor place to keep a mutable dependency.

Why these four SHAs

They are not newly resolved — they are the values this repository already pins in ci.yml, supply-chain.yml and the release workflows from the four earlier batches, all of which are green on main. So this adds no upstream code that is not already running here; it makes these nine files agree with the ones already pinned, and keeps a single SHA per action across the repo so the next bump is one sweep.

Risk

uses: values only. No permissions: block, step, trigger, matrix, runner or run: body is touched, and no action's version changes — only how it is addressed.

Verification:

• all 34 files under .github/workflows/ re-parsed with yaml.safe_load after the edit;
• each changed file loaded as a structure and compared against its HEAD version with uses: values masked — the diff is empty, confirming the change is pins and nothing else;
• git diff --stat is 17 insertions / 17 deletions across 9 files.

Not in this PR

Fifteen workflows still carry floating refs and belong in later batches, split by family. Three of them need a SHA that is not yet established anywhere in this repo and so want their own look rather than a sweep:

• browserstack.yml references browserstack/github-actions/*@master — a branch, not even a tag, so it is the weakest ref in the repo and deserves its own PR;
• i18n-autotranslate.yml / i18n-docs-autotranslate.yml use peter-evans/create-pull-request@v8, a third-party action that opens PRs;
• overhead-bench.yml / windows-enterprise-tls.yml pin actions/setup-python@v6 and supply-chain.yml has one github/codeql-action/upload-sarif@v3 left.

Also out of scope: TokenPermissions is now clean on this repo — all 34 workflows declare a top-level permissions: block — and no run: block interpolates ${{ github.event.* }}.

Product record

CI-only: every changed path is under .github/, which is exempt from the product-record gate.

No-PRD: CI/workflow-only change, all paths under .github/ (gate-exempt).

---

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.