ci: pin shared automation workflows to a full commit SHA

[tt-a1i]

Problem

feishu-pr-notification.yml and release.yml call reusable workflows from openpi-dev/automation at @main. Every action in this repository (ci.yml, pages.yml, labeler.yml) is pinned to a full commit SHA, and #671 notes that the repository only allows SHA-pinned actions. These two callers are the exception, and they are the most privileged workflows we have:

• feishu-pr-notification.yml runs on pull_request_target for fork PRs and passes FEISHU_PR_BOT_WEBHOOK and FEISHU_PR_BOT_SECRET.
• release.yml grants id-token: write for npm trusted publishing.

With @main, any change merged in openpi-dev/automation starts running here with those secrets and that OIDC authority on the next event, without review in this repository.

Value

Changes to automation reach OpenPI's secrets and publish identity only through a reviewed OpenPI PR, the same way SHA-pinned actions already work. This reverses the "follow main" choice from #279 on purpose. The cost is an SHA bump PR whenever automation changes, which has been rare: the last automation commit is from 2026-09-02.

Approach

• Pin both callers to ac8a4140e4ce458a2ed693c5ec9798946ccc0dda # main, the current main HEAD of openpi-dev/automation. This uses the same @<sha> # <ref> style as pages.yml.
• tests/github/automation-workflows.test.ts asserted @main. It now requires a 40-hex SHA with a # main comment and rejects any non-SHA automation ref.
• RELEASING.md and docs/contributing/feishu-pr-notifications.md now describe the pin.

pull_request_target review, at the pinned revision:

• The OpenPI caller grants contents: read and pull-requests: read, passes only the two Feishu secrets (not secrets: inherit), and never references the PR head ref. The existing contract test already enforces this.
• The reusable workflow has no checkout and no run: steps. It skips drafts and calls one action, itself SHA-pinned (actions/feishu-pr-notification@a681421). That action reads the event JSON, builds a sanitized card, signs it, and fetches the webhook. It has no child_process, no eval, and does no shell interpolation of PR titles or bodies.
• Conclusion: no PR code runs with secrets, and I found no injection path. The remaining exposure was that the automation reference could drift, which this PR closes. No further changes needed.
• labeler.yml (also pull_request_target) is already pinned and checks out nothing.

Validation

• bun run check: passed.
• bun run test: node 2315 passed / 0 failed; UI 1158 passed.
• tests/github/automation-workflows.test.ts: 6/6 pass. Reverting release.yml to @main makes the pin test fail as intended.
• Confirmed that both reusable workflow files exist at ac8a414 (gh api repos/openpi-dev/automation/contents/.github/workflows/<file>?ref=ac8a414…).
• Not exercised: a real release or Feishu notification. Opening this PR runs the pinned Feishu caller once.

Impact

• User-visible behavior: None.
• Model-visible context/tools: None.
• Runtime/lifecycle: None.
• Persisted config/data: None.
• Compatibility/risk: Touches CODEOWNERS-protected .github/workflows/**, so it needs review from @tt-a1i or @openpi-dev/release-managers. Future openpi-dev/automation changes take effect only after a PR here updates the SHA. For releases, the npm trusted publisher still validates the calling release.yml, which is unchanged apart from the ref.