ci: route cmux-next fast gates through fleet first
The cmux NEXT fast-gates workflow still routed its trusted Linux jobs through a single Blacksmith label or an unset pool variable. When that label started nothing, a PR's fast-gates verdict stayed queued. This PR routes the resolve, fast-gates, panic-ratchet and post jobs through the fleet-first Linux label, accepts only the declared Blacksmith overflow labels for a broker rerun, and adds the fleet label to actionlint's policy set.
Leo's rule: βBro, I thought we already had logic to automatically route stuff. How can we still have pins like this? I hate pins.β
The dispatch-only fast-checks.yml and PR-side ci.yml changes job are owned by #29934; this PR is the separate cmux NEXT fast-gates path.
Performance
| metric | before | after | delta | harness or run |
|---|---|---|---|---|
| Blacksmith minutes/day for cmux NEXT fast-gates defaults | 11-minute queued Blacksmith incidents (41265501114, 41265501033); no fleet-first route | 0 default Blacksmith minutes; Blacksmith remains bounded overflow after a stalled fleet start | default paid usage moves to fleet; overflow remains available | NOW queue evidence and .github/warm-sources.json (actions-cache) |
Validation: Focused workflow and runner-policy tests pass locally. The workflow and guard changes are ready for the fleet check at this PR head.
Agent session: agent session
π€ Generated with Claude Code