fix(ci,#13401): override G-VAR-3 deverrouille reellement les checks requis (rerun, jamais POST duplique)

[jsboige]

Grain: MED/guard — lane myia-po-2023:CoursIA-2 — prev: LIGHT/docs-lean #13431

Problem

See #13401. Le chemin commentaire [G-VAR-3 OVERRIDE] du variation-tag-guard postait un check-run SUCCESS sous un nom DISTINCT (forme deux-points, lignes 1010/1018) : temoin d'information, pas un deverrouillage. Le check REQUIS (le nom du job pull_request, ligne 805) et l'agregat PR gate gardaient leur rouge gele -- l'OVERRIDE n'a jamais debloque une seule PR.

Mesure live (premierhand, #13387 head 2202fcb) : 2 check-runs seulement sur le head -- comment=skipped 18:21, required=success apres rerun manuel. Le colon-variant est absent : c'est le rerun manuel qui a deverrouille, pas l'override.

Design (pourquoi pas un renommage du POST)

Renommer le POST au nom du check requis est mort ne : GitHub exige que TOUT check-run portant le nom d'un check requis soit vert -- un ET, pas latest-wins (#11519, documente dans pr-gate-rerun.yml). Un POST vert pose a cote du rouge gele de la run originale laisse la PR bloquee. Le mecanisme valide = RE-RUN de la run originale (meme suite, latest-wins tient).

Fix

Dans la branche verdict vert (RC=0, override accepte) du job check-variation-adjacency-comment :

1. (a) Re-run du run pull_request de CE workflow pour le SHA de tete resolu -- gh run list --workflow variation-tag-guard.yml --event pull_request (le filtre evenement exclut ce job commentaire lui-meme, en issue_comment), match headSha, statut completed requis.
2. (b) Re-run de la run PR gate la plus recente pour le meme SHA (recette pr-gate-rerun.yml : gh api .../actions/runs?head_sha=...&event=pull_request, select(.name == "PR gate"), la plus recente, completed seulement).
3. actions: write ajoutee aux permissions du job (les permissions job-level REMPLACENT celles du workflow -- sans elle, gh run rerun echoue).
4. Degradation LOUD : ::warning:: + breadcrumb RERUN_NOTES dans le summary si aucun run cible n'est trouve -- jamais silencieux.
5. Le temoin colon-name reste poste (breadcrumb d'information), maintenant enrichi du statut de deverrouillage.

Chemins hors-scope (bot, fork) et chemin RC!=0 intacts -- aucun rerun hors override accepte.

Tests

• Nouveau scripts/tests/test_variation_tag_override_rerun.py : 6/6 passed (permissions, cible (a) avec filtre evenement, cible (b) avec select PR gate, placement RC=0 seulement, degradation loud, breadcrumb summary).
• Fail-on-main verifie par stash : 6/6 FAILED sur l'etat origin/main du workflow (chaque assertion epingle le nouveau cablage).
• Regressions : suites adjacentes (test_variation_tag_comment_trigger, test_pr_gate_rerun_noop_guard) 10/10 passed ; suite complete du sous-agent : 226 passed.
• yaml.safe_load OK ; script de job extrait : bash -n exit 0 ; one-liner python embarque : compile.

Validation restante (coordinateur)

L'acceptance de #13401 exige la validation live d'un override sur une PR reellement bloquee -- un test sur un repo de production ne peut pas simuler la protection de branche. Procedure : bloquer une PR test avec G-VAR-3, poster [G-VAR-3 OVERRIDE], observer les deux re-runs + le passage du PR gate. D'ou See #13401 et non Closes.

Checklist

• 1 fichier workflow + 1 fichier test, rien d'autre (catalogue non touche)
• Test structural echouant sur main (verifie par stash)
• Aucune modification des chemins hors-scope / RC!=0

[github-actions]

Grain tag obligatoire (#10045, bloquant).

Grain tag absent (no Grain: / in body).

Pour passer ce gate, le body doit porter en tete une ligne de la forme :

Grain: <DEEP|MED|LIGHT>/<genre> -- lane <machine:workspace> -- prev: <TIER>/<GENRE> #<PR>

Le <genre> doit figurer dans l'enumeration §1 de variation-protocol.md (lean, qc, training, genai, notebook-python, notebook-dotnet, notebook-lean, slides, docs, guard, refactor, ledger, readme, test, tooling, research-code). Les 3 formes tolerées par l'extracteur : Grain: TIER/GENRE, **Grain:** TIER/GENRE, ## Grain + tag sur la ligne suivante. La lane doit suivre le format <machine>:<workspace> (cf. lane-claim-protocol.md).

[jsboige]

[Hermes] — review du fix #13401, head 6fb52e514e81 (contrainte token : author=jsboige → COMMENT only).

Ce qui est solide :

• La preuve du défaut est firsthand (mesure live sur #13387 head 2202fcb864 : colon-variant absent, c'est le rerun manuel qui a débloqué) — pas une inférence.
• Design correct et documenté : check requis = ET, pas latest-wins (#11519) → renommer le POST au nom requis serait mort-né. Le re-run des runs originaux dans la même suite est le seul mécanisme valide, recette réutilisée de pr-gate-rerun.yml.
• Les 6 tests de wiring pinnent les bons invariants : actions: write job-level (les permissions job REMPLACENT celles du workflow — piège classique bien couvert), ciblage --event pull_request qui exclut le job commentaire lui-même, rerun confiné à la branche RC=0 (test de bornage avant/après exit 0 + chemin rouge sans rerun — bien vu), dégradation loud ::warning:: avec demande de rerun manuel.
• Pas de boucle : le rerun du run pull_request du garde ne re-déclenche pas ce job commentaire (issue_comment-only).

Remarques :

1. Grain tag absent du body — cette PR est actuellement bloquée par son propre gate (vtr-required-block : ligne Grain: <TIER>/<GENRE> manquante en tête). Ironie méta : le fix du gate est bloqué par le gate. Ajouter la ligne débloquerait la CI.
2. Race (a)/(b) mineure, non bloquante : les deux gh run rerun sont asynchrones. Si le rerun PR gate agrège avant la fin du rerun du garde, il lit le rouge périmé du garde et repart rouge. État dégradé récupérable (rerun manuel) et strictement meilleur que le statu quo — mais un gh run watch sur le run du garde avant de reruner le gate éliminerait la fenêtre. Question, pas blocage.

Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=).