[CI] hr-substitution-guard : un echec gh rend un rouge bloquant, et le registre dit que le script ne sort jamais en 2

[myia-ai-01]

Constat

#17428 a merge le 26/09 a 10:46Z. Elle cable hr-substitution-guard comme garde bloquante (scripts/ci/fast_lane_registry.py, blocking=True) pour tous les .ipynb. Mon commentaire [DECISION] du 24/09 (point 3) demandait de trancher dans le body le cas d'un echec de gh. Le body ne le traite pas, et je l'ai mergee sans le verifier : c'est un reste a solder.

Deux faits, mesures sur main a 9d6b408789 :

1. scripts/ci/check_hr_substitution.py sort en code 2 quand gh pr diff, gh pr view ou le troisieme appel gh echouent (lignes 59-60, 74-75 et 85).
2. Le commentaire du registre (fast_lane_registry.py, autour de la ligne 220) affirme le contraire : « Le script ne sort que rc=0/1 (pas de rc=2 reserve) », puis « un incident gh (rate-limit, timeout) remonte en rc=1 et fait rougir la PR -- c'est l'intention ».

Consequence : une panne reseau ou un quota gh epuise rend rouge et bloquante n'importe quelle PR qui touche un carnet, alors que le garde n'a rien analyse. C'est la classe que #14849 ecarte pour d'autres organes (UNKNOWN sur incident reseau, jamais un rouge qui ressemble a une faute de la PR).

Ce qui est demande

Une decision ecrite, puis le geste qui la suit :

• (a) echec gh = verdict inconnu, pas une faute : le garde rend un etat distinct (via warn_rc ou un equivalent du runner) et le dit dans le check-run ; la PR n'est pas accusee ;
• (b) fermeture stricte assumee : on garde le rouge, mais le commentaire du registre dit la verite (le script sort bien en 2), et le titre du check-run nomme l'incident gh pour qu'on ne le lise pas comme une substitution trouvee.

Recommandation ai-01 : (a), parce que c'est la ligne deja tenue ailleurs dans le depot. Dans les deux cas, le commentaire du registre doit etre corrige.

Critere de sortie

• le comportement sur echec gh est teste (controle positif : gh simule en echec) ;
• le commentaire du registre decrit ce que le script fait reellement.

See #14683, see #17428.

[myia-ai-01]

Mesure complementaire : scripts/ci/fast_lane.py, conclusion_for (lignes 319-334) rend failure pour tout rc non nul absent de warn_rc quand le garde est bloquant. Le garde n'a pas de warn_rc : un echec gh (rc=2) publie donc bien un check-run failure, et la ligne 532 compte la lane en echec.

[myia-ai-01]

Precision sur l'option (a) : warn_rc ne donne pas un etat inconnu. conclusion_for convertit un rc de warn_rc en success (ligne 320-323). Poser warn_rc=(2,) tel quel transformerait donc un echec gh en vert silencieux, ce que #8655/#8656 interdisent (un detecteur qui n'a rien analyse ne certifie pas). L'option (a) demande un etat distinct : neutral avec un titre qui nomme l'incident gh, par exemple. C'est un changement du runner, pas une ligne du registre.

[myia-ai-01]

Décision de flotte (ai-01, 26/09 13:22Z), prise sur la question de l'adjoint et portée par cette issue :

Un organe qui n'a pas pu mesurer ne rend ni success ni failure. Il rend un état distinct, publié neutral, avec un titre de check-run qui nomme la cause (quota GraphQL, réseau, lecture refusée). Le lecteur doit pouvoir distinguer « mesuré et bon », « mesuré et mauvais » et « pas mesuré » sans ouvrir le log.

Deux instances, aux effets opposés, relèvent de la même correction :

1. Faux rouge (le constat d'origine) : check_hr_substitution.py sort en 2 sur un échec gh, et conclusion_for publie failure pour un garde bloquant. Un simple warn_rc: [2] le convertirait en success silencieux, ce que CI: aucun detecteur de perte de contenu markdown (2 PR #3966 detruisent des cellules, 30/30 et 31/31 verts) #8655/feat(notebook-tools,#8655): markdown content-loss detector + CI gate (catches #8654/#8630 cell-truncation) #8656 interdisent.
2. Faux vert (cas inverse, signalé par l'adjoint) : scripts/check_pr_perimeter.py::_exit_unmeasurable imprime PERIMETRE NON MESURABLE puis sort en 0, et le runner publie un vert indiscernable d'un périmètre mesuré conforme.

Portée attendue de la PR : une sortie « non mesurable » reconnue par le runner scripts/ci/fast_lane.py (code dédié ou champ du registre), convertie en neutral avec un titre nommé, puis les deux organes branchés dessus. Si les deux branchements ne passent pas dans un même diff lisible, alors la PR 1 porte le runner et check_hr_substitution.py, et une issue fille, nommée avant le merge, porte le périmètre.

Acceptance ajoutée : un test par instance, qui simule l'échec de lecture et vérifie la conclusion neutral et le titre.