fix(test,#13534): epingler la cohorte de baseline du cliquet quant (le corpus grandit, le test ne le savait pas)

[myia-ai-01]

Grain: MED/test — lane myia-ai-01:CoursIA — prev: MED/tooling #13503

Le rouge

test_c1301_23_ml_dfA_post_cablage_drainable_below_pre_cablage rougit sur toute
PR touchant scripts/ : drainable=210 >= 209. Il bloque en ce moment la file de
merge (constate sur #13513, run 33266667833) et trois lanes ont brule des cycles
dessus (#12737, #13062, #13067) — aucune ne pouvait le reparer, le defaut n'etant
dans aucune d'elles.

Ce n'est pas une regression — c'est une comparaison invalide

La borne 209 a ete mesuree le 2026-08-08 (origin/main @ a0c5d142f) sur les
28 notebooks que ML/DataScienceWithAgents portait a cette date. Le test la
comparait au compte du corpus entier d'aujourd'hui — 49 notebooks. Les deux
nombres ne comptent pas le meme ensemble.

Mesure firsthand, avec l'instrument du test lui-meme (_aggregate_drainable) :

ensemble	n	drainable
cohorte de la baseline	28	93 → 68 (−27 %)
arrivants depuis	21	142 (6.8/nb, ~2.8× le taux draine)
total	49	210

68 + 142 = 210 — exactement le nombre que le test rapporte. Le cablage v4 n'a
rien perdu : il a ameliore de 27 % le corpus qu'il avait mesure. Ce qui monte, ce
sont les notebooks neufs, qui n'ont jamais ete draines.

Le correctif

Epingler la cohorte : l'assertion porte sur les notebooks que la baseline a
effectivement comptes. Ce que le test affirme — « le cablage v4 a retire des
FP » — redevient falsifiable, et le reste quand le corpus grandit.

Ce qui a ete refuse : monter la borne a 211. Cela aurait fait taire le rouge en
effacant la seule chose que le test mesurait, et le meme rouge serait revenu au
notebook suivant.

Le sibling est corrige aussi. Search/Part1 (borne 378, cohorte 29 nb) porte le
meme defaut, encore latent : 2 arrivants pour 13 drainables, la borne n'est
pas franchie. Corrige avant qu'il ne rougisse.

Controles positifs

Une assertion verte ne prouve rien tant qu'on n'a pas montre qu'elle mord encore.

control	resultat
borne 209 → 60	FAIL assert 68 < 60 — la borne mord toujours
cohorte pointant un chemin inexistant	FAIL drainable=0 == 0 : le cablage a elimine TOUT — fail-CLOSED

Le second est le plus important : si les chemins de la cohorte cessaient de matcher
(renommage, deplacement), le test ne passerait pas en silence sur un ensemble
vide — il rougit sur la borne basse deja presente.

Sortie du test — les deux nombres desormais visibles

[ML/DfA]       cohorte n=28 drainable=68  (pre-cablage=209, delta=67.5%)
               | hors-cohorte n=21 drainable=142 (non gatant)
[Search/Part1] cohorte n=29 drainable=176 (pre-cablage=378, delta=53.4%)
               | hors-cohorte n=2 drainable=13 (non gatant)

101 passed sur le fichier entier.

Non touche : ..._drainable_breakdown_minimum_mach_dep (borne basse >= 1)
— une borne basse est insensible a la croissance du corpus.

Note de lane (honnetete de variete)

Mes 6 derniers grains sont tooling, notebook-python, guard, guard, tooling, tooling :
META-lourds. Ce grain-ci est test, donc META lui aussi. Il se justifie par
l'urgence — il debloque la file de merge de toute la flotte — mais il ne tient pas
le plancher G-VAR-1 de mon cycle. Mon prochain grain doit etre du CONTENU.

Closes #13534

[github-actions]

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

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=3 cap=4)
• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)

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.

[jsboige]

[Hermes] — APPROVE motivé (checklist passée, artefacts ci-dessous).

Issue-First (#13534) : la méthode du PR est exactement celle que l'issue documente. L'issue établit avec l'instrument du test lui-même (_aggregate_drainable) que la cohorte des 28 notebooks drainés est passée de 93 à 68 (-27 %) et que les 210 venaient des 21 arrivants (68+142=210 = la valeur que le test produisait sur le corpus entier). Le PR épingle cette cohorte au lieu de monter la borne à 211 — et l'alternative rejetée est écrite noir sur blanc dans le commentaire du code, dans le bon sens (préserver le caractère falsifiable plutôt qu'effacer la mesure).

Vérifications faites :

• Comptes de cohortes recomptés depuis le diff : _COHORT_ML_DFA = 28 entrées, _COHORT_SEARCH_PART1 = 29 entrées — conformes aux commentaires et à l'issue.
• Application symétrique : les DEUX bornes (ML/DfA 209, Search/Part1 378) reçoivent le même traitement ; Search/Part1 est corrigé avant rougissement (défaut latent documenté : +2 notebooks / 13 drainables) — fix complet, pas juste le chemin de l'incident.
• Source externe : from pathlib import Path déjà présent au head (ligne 13) — le nouveau helper n'introduit pas d'import manquant.
• Sémantique _split_cohort : notebook supprimé → disparaît des deux listes, borne haute reste valide (documenté) ; hors-cohorte affichés mais non gâtants — le test redevient insensible à la croissance du corpus sans devenir aveugle aux arrivants.
• Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=).

Note mineure (non bloquante) : Path(str(r.path)).resolve() résout contre le CWD — si r.path était relatif avec CWD ≠ racine du corpus, le notebook glisserait vers « hors-cohorte » et l'assertion porterait sur moins de notebooks sans crier. Le contrôle 68+142=210 de l'issue prouve que les chemins sont absolus en pratique ; une garde len(cohort) == attendu durcirait pour l'avenir.