Run validate on pull requests (with approval gate for forks)

[aatchison]

What changed?

1. validate.yml now triggers on pull_request (base main) in addition to push.
2. Concurrency group is scoped per PR / ref instead of a single global validate group.

Why?

Fork PRs are never validated today. validate.yml triggers only on push, and a fork PR pushes to the fork, never to this repo — so no run is ever created here. Confirmed on #1746: zero workflow runs for its branch, and zero runs repo-wide in action_required or waiting. The "Approve and run workflows" button had nothing to act on, because there was no run.

main is excluded from the push trigger as well, so merging doesn't validate either. The next workflow to touch merged code is deploy-staging.yml, which deploys to stage. Net effect: an external contribution's first real exercise is a staging deployment.

#1746 (npm → pnpm) is the worked example — an entire frontend build-system rewrite, approved by three reviewers, with no check ever having run against it. It also carried a bug where pnpm run build -- --mode $APP_ENV silently dropped the mode and would have shipped a bundle with empty VITE_* values to S3. Caught by hand; CI wouldn't have caught it either, but CI is the layer that should have had a chance.

Is it safe to run fork code?

Yes, and this repo is already configured for it:

• On pull_request from a fork, GitHub withholds every repository secret and forces GITHUB_TOKEN to read-only, regardless of the permissions: block.
• fork-pr-contributor-approval is already set to all_external_contributors, so each fork run waits for a maintainer to click Approve and run workflows. This PR makes that existing setting actually do something.
• Every job in validate.yml references zero secrets.* and zero vars.* — lint, build, vitest, pytest, nginx config test. There is nothing for untrusted code to reach even inside the sandbox.
• This is pull_request, not pull_request_target. The dangerous pattern is pull_request_target + checking out PR code, which gets secrets and a write token. pr-merged.yml uses pull_request_target correctly and is untouched here.

Concurrency fix

concurrency:
  group: validate          # before: global
  group: validate-${{ github.event.pull_request.number || github.ref }}   # after
  cancel-in-progress: true

A bare group name is global across the repo, so two people pushing to unrelated branches silently cancel each other's checks. Adding a second trigger would have made that worse.

Open question for reviewers

Internal branches with an open PR now get two runs — one from push, one from pull_request — since the concurrency keys differ by design. Options:

• Accept the duplicate (what this PR does): every internal push stays validated, at 2× runner cost while a PR is open.
• Drop the broad push trigger, keeping pull_request + push to main: no duplicates, but internal branches aren't validated until a PR exists.

Left as a draft deliberately — happy to switch to the second shape if that's the team's preference.

Applicable Issues

Follow-up from review of #1746.

🤖 Generated with Claude Code