ci(signal): turn a red check into a label a poller can find in one call

[wshallwshall]

Closes the signalling half of BACKLOG #1402 and #1403, both filed in PR #715.

The problem, measured. When a required check fails, nothing tells any session. Exactly two workflows carry an if: failure() step and both only fail the job. So the only route from a red to somebody acting on it is fetching the check rollup of every open pull request, one at a time, which is expensive enough that it does not get run.

What this adds. A workflow_run job that labels the pull request ci-red when CI, Security, CodeQL or backlog-hygiene fails. Noticing then costs one gh pr list --label call across all pull requests.

It is not a push, and the file header says so. GitHub still cannot reach into a session. This makes the poll cheap enough to run often, which is the achievable version.

Why workflow_run rather than a failure step in each workflow. A failure step cannot see other workflows' runs, and the required contexts span five of them. workflow_run observes all of them from one place, runs from the default branch with its own permissions, and never executes head code. nightly-notice.yml already uses the trigger.

The merge-queue case. A merge_group run has no github.event.pull_request, the same fact that collapsed backlog-hygiene's concurrency key until #711 keyed it on github.ref. Its ref does carry the number, as gh-readonly-queue/<base>/pr-<N>-<sha>, so an ejection is still attributable.

Reds with no pull request go to one standing issue, matched on exact title so search ranking cannot spawn a second tracker. Not a rare branch: 4 of the 9 failures in the last 200 runs had no PR behind them.

Hardening. Every github.event value reaches the scripts through env, since a branch name is chosen by whoever opened the branch. Top-level permissions are contents: read; the one job that writes elevates for itself. actionlint passes.

Not watched, deliberately: CLA Assistant. A CLA failure is the contributor's to resolve and needs no attribution; labelling it would train readers to ignore the label.

🤖 Generated with Claude Code

[wshallwshall]

Reviewed, and labelled

Recording what I actually checked, so the label means something specific rather than "someone looked".

The measured claims, re-run against origin/main

Claim	How I checked	Result
Exactly two workflows carry if: failure(), and both only fail the job	git grep -n "failure()" origin/main -- .github/workflows/	Holds. branch-leak-scan.yml:100 and security.yml:303, and both steps only echo
nightly-notice.yml already uses workflow_run	read its on: block	Holds. workflow_run over CI, Security, DAST
#711 keyed backlog-hygiene on github.ref	backlog-hygiene.yml:43	Holds
Nothing on main reads head_ref	git grep -n head_ref origin/main -- .github/	Holds. Zero hits
The four watched names resolve	listed every workflow's name: at origin/main	Holds. CI, Security, CodeQL, backlog-hygiene all exist

The zizmor.yml edit is scoped to dangerous-triggers only and adds one filename. Nothing else widened.

The tests can fail

The suppression rests on four properties, so I checked the tests that pin them are not vacuous. I extracted this branch's workflows plus tests/test_failure_signal.py into a scratch tree, confirmed 6 passed, then mutated the workflow once per test and restored between runs:

Mutation	Test that went red
added - uses: actions/checkout@v4	test_it_pulls_in_no_third_party_actions
top-level contents: write	test_it_is_least_privilege_and_cannot_modify_code
interpolated ${{ github.event.workflow_run.head_branch }} into a run: body	test_every_event_value_reaches_a_script_through_env
dropped && [ "$RUN_EVENT" = "merge_group" ]	test_the_merge_queue_parse_is_gated_on_an_event_a_fork_cannot_produce
added a watched name no workflow answers to	test_every_watched_workflow_exists
added `

Each mutation reddened exactly the test that claims to guard it, and only that one. The suppression is pinned, not asserted.

The resolve script behaves as documented

Ran it standalone against seven payloads with a jq stub:

Input	Result
[{"number":42}], pull_request	42
[], merge_group, gh-readonly-queue/main/pr-717-abc123	717
[], push, main	empty
null, schedule	empty
[], merge_group, ref with no number	empty, and does not abort under pipefail
[], pull_request, branch named pr-999-evil	empty. The hostile name never reaches the parse
[], merge_group, .../pr-1-x-pr-999-y	1, the queue's own prefix

Also green on this branch: zizmor, and repo harness tests (ubuntu-latest), which is the leg tests/tooling_manifest.txt routes the new file into.

Two things worth raising, neither changing the verdict

Nothing removes ci-red. When CI later goes green the label stays, so gh pr list --label ci-red accumulates pull requests that are already fixed. That is the same decay this file's own CLA paragraph refuses: labelling something that does not need attribution "would train readers to ignore the label". review-gate.yml solves the mirror problem by removing its label on synchronize. A sibling job on conclusion == 'success' that removes the label would close it, and I would file it rather than block on it.

The "4 of the 9 failures in the last 200 runs" figure did not reproduce, because the window has moved. Over the most recent 500 runs I count 28 failures: 20 pull_request, 5 merge_group, 2 push, 1 schedule. That still supports "not the rare branch" for the no-payload case. But 5 of those 8 are merge_group, which this workflow attributes from head_branch rather than sending to the standing issue, so the standing-issue branch itself was 3 of 28 in my window. The number is defensible; it reads as slightly larger than what it covers.

Merge order

The workflow header and the body cite BACKLOG #1402 and #1403, which PR #715 files and which are not on main yet. The numbers are allocated so they cannot mis-resolve onto somebody else's work. Land #715 first, or the citations point at nothing in the meantime. No gate will catch it: dangling_citation_check.py defaults to docs/**/*.md, and the diff-scoped citation gate only fires on a number added beside a ledger path.