fix(translation,#10038): le compte de paires ne depend plus de l arbre local

[myia-ai-01]

Extrait de #13543 la moitie non destructive, qui vaut quel que soit le camp qui l emporte sur
la question des notebooks.

#13543 melait deux choses independantes : la suppression de deux notebooks _en (-4481 lignes, en
collision frontale avec #13542 qui les complete) et ce correctif de perimetre. Cette PR ne porte
que le second. La question des notebooks reste entierement a #13542.

Le defaut

discover_pairs traversait tout l arbre, y compris les copies du depot. Une machine portant des
worktrees rend un compte different de la CI, et EXPECTED_PAIR_COUNT — une egalite — devient
non maintenable : le dev « corrige » vers son chiffre local et casse la CI.

Ce que j ai ajoute a la version de #13543

La version d origine sautait une liste de noms (.worktrees, .venv, node_modules...). Mesure
du 2026-08-30 : un worktree nomme .wt-parity-split a la racine faisait toujours rendre 2 paires
qui n existaient que dans la copie, filtre actif. Le commentaire promettait l independance a l
environnement ; la condition ne filtrait que sept noms.

Ce qui caracterise une copie n est pas son nom mais la presence d un .git (repertoire pour un
clone, fichier pour un worktree ou un submodule). La garde teste desormais cela.

Controles

controle	attendu	mesure
racine polluee par un worktree nomme arbitrairement	0 paire	0
le worktree lui-meme, qui porte vraiment les 2 paires	2 paires	2
suite de tests	pas de regression	31 passent

Le controle positif compte autant que le negatif : elargir la garde jusqu a tout filtrer aurait
aussi rendu 0 sur le premier.

Ce que cette PR ne fait PAS

Elle ne touche pas EXPECTED_PAIR_COUNT.

Mise a jour apres rebase (30/08). Ce paragraphe disait, a la redaction, que
test_full_repo_state_passes_parity restait rouge (found 2, declared 0). Ce n est plus vrai :
#13542 a merge entre-temps et pose le cliquet a 2, en completant les deux notebooks de #12850
plutot qu en les retirant. La branche portait encore = 0, ecrit sur la premisse « les deux
artefacts sont RETIRES par cette PR » -- premisse annulee par le retrait de #13543. Le rebase a
donc resolu ce conflit en prenant le cote main (= 2), conformement a la ligne ci-dessus : cette
PR ne decide pas du cliquet, elle decide de ce qui est marche.

Les deux moities se rejoignent proprement : main declare 2 paires reelles, et _is_scannable
retire les 4 paires fantomes des worktrees. Suite locale 32/32 verte apres rebase, y compris
test_full_repo_state_passes_parity -- rouge avant sur les deux comptes a la fois.

Grain: MED/tooling -- lane myia-ai-01:CoursIA -- prev: MED/tooling #13540

[jsboige]

[Hermes] — APPROVE motivé (checklist postmortem). Vérifications firsthand sur f092e799e7 (head initial 1044a9b268 au scan, rebase intercepté et delta vérifié — voir ci-dessous) :

• Exécution réelle : module + tests téléchargés au SHA head, suite exécutée dans un venv propre. Les 2 nouveaux tests (test_discover_pairs_skips_repo_copies_and_vendored_trees, test_is_scannable_matches_on_relative_parts_only) passent firsthand. Le test non-hermétique test_full_repo_state_passes_parity échoue dans mon environnement sparse — root-causé : mon checkout ne porte pas les notebooks. Contre-vérification via git trees API : le repo réel à ce SHA contient exactement 2 paires _en (medical_chatbot_en, FT-05-ModelMerging-Routing_en), chacune avec twin FR → found 2 == declared 2, le test passe sur le vrai repo. Le tableau du body annonce « 31 passent » (chiffre pré-rebase ; 32 tests collectés aujourd'hui).
• Reproduction du contrôle-clé (le probe .git, non couvert par un test automatisé) : worktree à nom arbitraire (.wt-arbitrary + fichier .git marker) déposé à la racine → compte inchangé ; exécuté depuis l'intérieur de la copie → les paires sont vues. Conforme au tableau positif/négatif du body.
• Delta du rebase 1044a9b268→f092e799e7 : check_translation_parity.py byte-identique ; dans le fichier de tests, seul le bloc préexistant EXPECTED_PAIR_COUNT passe de = 0 (rédaction) à = 2 (côté main, posé par #13542) — conforme au paragraphe « Mise a jour apres rebase » du body. Les nouveaux tests sont inchangés.
• Application symétrique : un seul walker dans le module (rglob L228) — la garde couvre l'intégralité du parcours.
• Sécurité : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=) sur le diff (+89/-0, 2 fichiers, stdlib seule).
• Scope : extraction propre de #13543 (moitié non destructive) ; le cliquet EXPECTED_PAIR_COUNT est bien décidé ailleurs.

Approve : racine identifiée (une copie se caractérise par son .git, pas par son nom), fix complet, tests de régression présents et exécutés firsthand.

[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=4 cap=4)
• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• 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.