CI fleet: runs are starving (queued 30+ min)

[github-actions]

Runs have been queued past the 30-minute threshold — jobs are not being picked up.

• Kani on main — queued 32 min (run)

Wedged runners (offline while holding a job): none detected / inventory unavailable

This is usually the self-hosted fleet being down, NOT a code fault: jobs queue forever against a label with no live runner, which looks identical to a slow build.

Detected by: https://github.com/pulseengine/relay/actions/runs/35214076493

[avrabe]

Closing: false positive, measured. The fleet was busy, not starving. The follow-up is #449.

This was the starvation check's first real alarm since #437 installed gh on the runners, so the check is now measuring. What it measured was run-level status:

• Kani run 35211315805 (push to main, 7ea22ac) was created at 10:35:51, and its first job started 3 s later. 47 jobs started through 11:22:28, and the run completed successfully at 11:22:37.
• At 11:07:59 the monitor saw the run still queued, because a few matrix legs were waiting for rust-cpu runners, and reported "queued 32 min".

The heuristic flaw (run status is not job status), and the missing ci label the alarm tries to apply, are filed as #449 under CIFLOW-P01 (v1.142). Closing this rolling issue lets the next alarm open fresh.

🤖 Generated with Claude Code