HW CI: fix fork-PR dispatch (pull_request_target)

[bwhitman]

The bug

The hwci-ok label gate (#745) can't actually bench a fork PR. Two reasons, found while debugging why labeling fork PR #744 did nothing:

1. No secrets for forks. A fork's pull_request workflow is denied all repository secrets (GitHub's security model — only a read-only GITHUB_TOKEN). So the dispatch step can never read HWCI_BRIDGE_TOKEN, and the cross-repo dispatch to tulipcc is impossible from a fork. The label gate as written is structurally unable to work for forks.
2. Timing race (secondary): fix: make reverb allocation failure safe (mirrors existing echo guard) #744's label was added 37s after the gate merged, before GitHub recomputed the PR's merge-ref, so the labeled event evaluated the pre-gate workflow and fired nothing.

The fix

Switch the trigger from pull_request to pull_request_target, which runs in this repo's trusted context — so it has HWCI_BRIDGE_TOKEN and always uses main's workflow (no merge-ref race).

 on:
-  pull_request:
+  pull_request_target:
     types: [opened, synchronize, reopened, labeled]

Why this is safe (the usual pull_request_target footgun does NOT apply)

The classic pull_request_target vulnerability is checking out and running the PR's code while secrets are in scope. This job never does that — it has no checkout, runs no PR code, and only reads head.sha (a hash) + number (an int) to fire the dispatch. The fork's code only ever runs downstream on the bench, which is precisely what a maintainer authorizes by applying hwci-ok.

• Gate is unchanged: same-repo OR hwci-ok label. Only maintainers can label.
• Unlabeled fork PRs: the job's if skips before anything privileged happens.
• Same-repo PRs: unaffected (still auto-dispatch; now always with secrets present).

Testing after merge

Re-apply hwci-ok to fork PR #744 (rt-rtos's reverb-OOM fix) — it should dispatch, bench, and comment back. The label is already on, so remove + re-add to fire a fresh event.

🤖 Generated with Claude Code