fix(pr-pipeline): report red per-merge full runs so red-main fix issues file without waiting for the schedule #8896

Refs: #7535, #8805

Problem

post-merge-demotion-alert.yml triggers on workflow_run completions of pr-require-checks on main. The full CI run that pr-merge starts after every merge never produces that event, so the red-main report, and with it #8805's fix-issue filing, only sees two kinds of run: scheduled runs (cron 17 9,16 * * *) and runs a person dispatches.

The repo already states this: .github/workflows/pr-merge.yml:40-41 reads "That run raises no workflow_run event (GITHUB_TOKEN started it), so post-merge-demotion-alert.yml never sees it." The full run is dispatched with GH_TOKEN: ${{ github.token }} (pr-merge.yml:1113-1117 in dispatch-full-run, and :187-191 in post-merge-dispatch).

Evidence (7 days to 2026-10-21)

Alert runs matched to upstream pr-require-checks runs on main, counted as an alert created 0-6 s after the upstream run completed:

Example: red run 39638634453 (2026-10-21 16:52Z) produced no alert run. GitHub's GITHUB_TOKEN page says "events triggered by the GITHUB_TOKEN will not create a new workflow run", except workflow_dispatch and repository_dispatch. The events page says nothing specific about workflow_run, so the claim that a GITHUB_TOKEN run's completion raises no workflow_run rests on the counts above.

Effect

A red main that persists gets a fix issue only at the next scheduled run, up to about 17 hours later (the gap from 16:17Z to the next day's 09:17Z). A red that recovers before that run never gets one. For a short red that is the right outcome; for a lasting one it is too slow.

Proposed fix (option A)

When dispatch-full-run's waited-for run, or its single re-run, ends in failure, have that job dispatch post-merge-demotion-alert.yml through workflow_dispatch, passing the run id. A workflow_dispatch sent with GITHUB_TOKEN does create a run. Alternatively, the job could call the report logic directly. Either way it keeps the same token and adds no App grant. The alert workflow would need a workflow_dispatch input that it validates: a run of pr-require-checks on main, in this repository.

Other options considered:

• B, a scheduled poll for red dispatched runs: adds latency and needs dedupe state.
• C, dispatching full runs with the lanes App token: a trust-path change, and report-red-main skips App-sent events (post-merge-demotion-alert.yml:598-599). Not recommended.

pr-merge.yml is a merge-gate file, so the owner merges the change, after GitHub Security & Cost reviews it.