ci(#14283): route golden-set-execute vers le pool self-hosted Linux

[jsboige]

Grain: LIGHT/tooling — lane myia-po-2024:CoursIA — prev: MED/test #14383

See #14283 (fin de chantier, item 1 du dispatch ai-01 du 2026-09-02) — l'epic reste ouverte : item 2 (mesure quarto-actions/setup) en cours.

Ce que fait cette PR

Migration du dernier job trivialement migrable de notebook-execution-required.yml vers le pool self-hosted Linux : golden-set-execute (3ᵉ job, ligne ~229). Les deux jobs frères (detect-changes, validate-static) roulent sur le pool depuis la tranche 3c ; celui-ci est le dernier qui restait sur ubuntu-latest.

Pourquoi trivial : ses seules dépendances actions sont actions/setup-python@v5 (toolcache monté dans l'image) et actions/github-script@v7 (node embarqué du runner) — pas de Docker, pas de GPU.

La forme est la forme canonique du chantier :

• runs-on: [self-hosted, coursia-ephemeral, coursia-linux] statique (une expression lèverait DYNAMIC_RUNS_ON dans check_self_hosted_runner_policy.py) ;
• garde anti-fork au niveau job : if: github.event.pull_request.head.repo.full_name == null || github.event.pull_request.head.repo.full_name == github.repository ;
• rien à ajouter côté politique : le workflow est déjà dans SELF_HOSTED_WORKFLOW_ALLOWLIST.

Le workflow liste son propre chemin dans ses triggers pull_request → cette PR exerce le job migré de bout en bout.

Produit à vérifier (pas seulement le vert)

Le dispatch le dit : un job routé vers une machine sans l'outil attendu peut être muet (sortie || true → exit 0 sans rien poster). Le produit attendu de ce run est le commentaire PR « Golden-Set Execution (H.7 P3) » avec la table des notebooks certifiés — posté par le job migré lui-même. La vérification post-merge se fait sur ce commentaire, pas sur la couleur du check.

Retour arrière

Remettre runs-on: ubuntu-latest + retirer le workflow de l'allowlist (documenté en commentaire dans le YAML, même forme que les tranches précédentes).

Validation

• Diff = 1 fichier, 9 lignes (runs-on + garde + commentaires de routage) — aucune logique du job modifiée.
• Le run de la PR elle-même est la validation : le job exécutera le golden-set Papermill sur le pool (timeout 20 min inchangé).

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2024:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-02) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=3 genre=7 cap=4)
• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=3 genre=7 cap=4)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	3.0s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	3.3s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	4.5s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	4.1s
Search-1-StateSpace.ipynb	✅ SUCCESS	3.1s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.7s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	22.8s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	7.1s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[jsboige]

[Hermes] — CoursIA #14386 golden-set-execute → pool self-hosted Linux (#14283, item 1). Diff 10+/3-, 1 fichier.

Vérification réelle (le produit, pas la couleur) : le body demande de vérifier le commentaire « Golden-Set Execution (H.7 P3) » posté par le job migré — présent sur cette PR, 8/8 notebooks certified reproducible (2.1-Workflow-ML 3.0s … Search-1-StateSpace ✅). Le job routé sur le pool a donc tourné de bout en bout et posté son produit : la migration est exercée, pas seulement déclarée.

• Garde fork if: au niveau job : forme canonique — pour les events non-PR (push/dispatch), github.event.pull_request.head.repo.full_name == null s'évalue à vrai (accès propriété sur null → null), le job tourne ; fork PR → skip. Cohérent avec les tranches 3c.
• runs-on statique conforme (pas d'expression → pas de DYNAMIC_RUNS_ON), commentaires de routage + retour arrière documentés dans le YAML même.
• L'ancien commentaire « No if: needed » correctement réécrit (le if: ne porte plus que la garde fork) — pas de commentaire mensonger résiduel.
• Security scan : 0 match.

LGTM au fond (contrainte token : COMMENT only — self-review). Item 2 de l'epic (mesure quarto-actions/setup) reste ouvert côté #14283, cette PR ne le prétend pas couvert.