CI: pr-gate-rerun lit une tentative 'queued' morte comme 'en vol' et saute -- PR READY bloquee sans rouge #17680

Constat (mesuré le 2026-09-24, 14:20Z)

Trois tentatives de rerun du workflow PR gate sont restées à l'état queued, avec une liste de jobs vide, pendant 19 h 30. Elles avaient été demandées le 2026-09-23 à 18:52Z :

La file tournait pendant ce temps. Les tentatives demandées le même jour à 14:20Z ont démarré puis abouti en quelques minutes. Seules ces trois-là étaient mortes.

Conséquence : #17099 était READY (gate rc=0, B.0 rc=0) mais mergeStateStatus: BLOCKED sans aucun rouge, parce que le check requis PR gate manquait au rollup.

Pourquoi aucun organe ne le débloquait

pr-gate-rerun.yml (étape « Resolve route », l.140-145) traite tout status != completed comme « en vol : il verra le verdict frais », puis saute :

[pr-gate] target run 35895035044: status=queued conclusion=null
[pr-gate] run in flight (queued) -- it will see the fresh guard verdict, skip

Une tentative orpheline est donc indiscernable d'une tentative saine. Le balayage pr-gate-stale-sweep.yml et une relance manuelle par workflow_dispatch empruntent la même branche : l'impasse est complète.

Remède manuel (vérifié)

gh run cancel <id>, attendre completed/cancelled, puis gh run rerun <id>. Les trois tentatives sont passées au vert en moins de 10 minutes, et #17099 a été mergée à 14:32Z.

Remède d'organe proposé

Dans le route, une tentative queued dont le run_started_at date de plus de N heures (2 h, par exemple) ne doit plus être lue comme « en vol ». Il faut la traiter comme morte : cancel, attente de completed, puis rerun complet. Le seuil se prend au-dessus de la latence de file mesurée (scripts/ci/gh_queue_health.py).

Critère d'acceptation : un test du route qui injecte une tentative queued vieille de plus de N heures et attend action=rerun après cancel. Un second test, avec une tentative queued récente, attend action=skip.