fix(ci,#14976): pr_gate conclusion-first + STARVED nomme le couple status/conclusion

[jsboige]

Grain: MED/tooling -- lane myia-po-2026:CoursIA -- prev: MED/tooling #15004

pr_gate : un check-run fige (conclusion terminale + status in_progress) pollue jusqu'a STARVED

Closes #14976

Le defaut

scripts/pr_gate.py:483 (classify) :

if status in STATUS_PENDING or not conclusion:
    pending.append(name)

Le or court-circuite sur son premier membre : un conclusion terminal ne
peut pas racheter un status fige. Or conclusion est autoritatif (l'UI
GitHub affiche ce job en vert). Mesure sur #14967 (2026-09-06) : Detect notebook changes etait a status=in_progress avec conclusion=success
90 min apres le completed_at de son propre job, confirme sur deux endpoints
independants. Le PR gate a poll ce job vert jusqu'a l'expiration du budget
(45 min) et a verdicte STARVED sur une PR dont rien n'etait rouge.

Le fix

1. Conclusion-first (classify) : une conclusion terminale clot le check,
   quel que soit status. status ne decide que si conclusion est nul --
   et alors le check est pending de toute facon.
2. Couple observe dans pending (_pending_label) : chaque constituant
   en attente rend nom [status/conclusion]. Le message STARVED nomme donc
   le couple reel : un Detect notebook changes [in_progress/success] est
   immediatement distinct d'un Slow CI [in_progress/none] (l'inverse etait
   ce qui a coute le diagnostic de 90 min).
3. Geste de reparation dans le message : un constituant portant une
   conclusion terminale est wedge, pas lent -- relancer son run ENFANT
   (gh run rerun <id>), jamais le gate. Le piege est documente : relancer
   l'agregateur ne repare rien, il re-poll le meme enregistrement fige.
4. STATUS_PENDING (constante devenue morte) supprimee.

Controle positif (acceptance 2)

Les tests nouvellement ajoutes sont ROUGES sur le code non-fixe (verifie
: 5 failed avant le correctif), verts apres (113 tests pr_gate passent).
Le cas fige {status:"in_progress", conclusion:"success"} tombe dans ok,
{status:"in_progress", conclusion:"failure"} tombe dans bad.

Acceptance (issue, point par point)

#	Critere	Etat
1	classify traite une conclusion terminale comme terminale	Oui {status:in_progress, conclusion:success} -> ok ; failure -> bad
2	Controle positif en test (rouge avant / vert apres)	Oui verifie avant/après correctif
3	STARVED nomme le couple status/conclusion observe	Oui nom [status/conclusion]
4	Geste de reparation (rerun run ENFANT, jamais l'agregateur) consigne	Oui dans le message STARVED + docstrings

Perimetre

2 fichiers : scripts/pr_gate.py, scripts/tests/test_pr_gate.py

[clusterManager-Myia]

Vérifié le diff + exécuté les tests à la SHA head (26b18a3). Les 8 tests #14976 (frozen check-run, pending label, STARVED message child-rerun) passent tous. Le test test_completed_without_conclusion_is_pending_not_pass reste vert. Le changement supprime bien le test status-first (status in STATUS_PENDING or not conclusion) au profit du test conclusion-first (not conclusion), conforme à la mesure #14967 (record figé in_progress/success 90 min après completed_at).

Les 3 échecs observés dans mon run local (test_derive_always_on_reads_real_workflows_and_excludes_self, test_advisory_jobs_roster_*) sont environnementaux : ils appellent derive_always_on_jobs() qui lit le vrai .github/workflows du repo, absent de mon checkout isolé — PAS causés par ce diff. Le roster retourne 0 jobs car aucun workflow réel n'est présent localement.

Le verdict passe de status-first à conclusion-first : c'est le bon correctif, le message STARVED nomme maintenant le geste de réparation (rerun du CHILD run). Solide, documenté, testé.