ci: bind PR helpers to workflow revision

[VioletQwQ-0]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

Related to #28419 (CI Required / coverage failure reporting)
Related to #27291 and #27293 through #28529's CI startup blocker

What this PR does / why we need it:

pull_request_target currently checks out .github/ci from the pull request base SHA in the change-scope and ci-required jobs. A 4.2-dev pull request can therefore load a workflow that references change-scope.cjs while its base commit does not contain that helper, failing before product tests start with Cannot find module '.github/ci/change-scope.cjs'.

Both jobs now load the repository-owned CI helper from ${{ github.workflow_sha }}, the commit that supplied the running workflow. The PR base and head SHAs remain event metadata only, and all checkout credentials remain disabled. A checkout-independent provenance step writes the workflow, base, and head SHAs before loading the helper, so missing-helper or checkout failures retain diagnostics. No test routing, required-check policy, or product code is changed.

The existing 3.0-dev route and failure semantics remain unchanged. This PR is intentionally separate from #28591, whose purpose is cancelling doomed PR runs.

Validation

• Baseline red check: the old workflow fails the trusted workflow-SHA checkout contract.
• node --test .github/ci/change-scope.test.cjs (10/10 passed)
• The fixture parses the actual checkout configuration for both jobs, resolves the event expressions against separate base/workflow/head trees, and executes the selected workflow helper. The base tree lacks the helper, the workflow tree contains the trusted classifier and verifier, and the head tree contains a malicious same-name helper. Both jobs select the workflow tree; the classifier and verifyResults are executed from that same trusted version.
• The contract test rejects a floating main ref, requires provenance before checkout, and executes the provenance shell against a simulated checkout failure to verify the summary remains available.
• actionlint v1.7.12 .github/workflows/entrypoint.yaml (passed)
• git diff --check (passed)
• The first CI run was correctly blocked by an invalid PR reference to fix(lockservice): backport stale empty-lock recovery to 4.2-dev #28529 (a PR, not an issue). The body now references valid issues [Bug]: UT coverage producer hits 60-minute timeout and cascades Coverage failure #28419, [Bug]: Concurrent Epinions trust batches panic in LockOp #27291, and [Bug]: Aborted Epinions load leaves an empty lock and panics on DROP TABLE #27293.
• After this PR merges, GitHub's pull_request_target behavior uses the repository default-branch workflow source; a fresh fix(lockservice): backport stale empty-lock recovery to 4.2-dev #28529 run can therefore be created directly without a 4.2-dev CI-file backport. That run must prove the workflow SHA contains this fix, classification succeeds, and required tests actually start. See GitHub's change.

QA required: no; this is a workflow/test-only change and does not alter MatrixOne runtime behavior. Complete CI startup and classification validation is a post-merge check.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[XuPeng-SH]

Reviewed exact head 7ca9d71 against base 065a675. No concrete blocker found.

Both classifier and final verifier now load the same immutable, repository-owned workflow revision rather than an unrelated PR base or untrusted head. The explicit target repository and disabled persisted credentials preserve the trust boundary; SHA values are passed through environment variables and quoted in the checkout-independent provenance step. Missing checkout/helper errors still fail the job, with provenance already written. Scope/revision checks, required-job AND gating, cancellation behavior, reusable-workflow calls and job names are unchanged. Reruns retain the executing workflow/helper pairing rather than following floating main.

Reviewed the complete diff, full entrypoint and helper consumers, malicious-head/missing-base fixtures and provenance failure test. GitHub's published pull_request_target default-branch change supports the stated target problem: https://github.blog/changelog/2025-11-07-actions-pull_request_target-and-environment-branch-protections-changes/ . Author reports 10/10 Node tests, actionlint and diff check; I did not rerun them or wait for CI. Actual release-branch startup remains the explicitly documented post-merge verification, not something this source review claims to have executed. Head/base rechecked before submission.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request