fix(translation): valider l'invariant du pivot hash_<src_lang> == src_hash (aucun check ne le couvre)

[jsboige]

Constat

scripts/translation/extract_cells_to_csv.py pose un invariant de construction sur la ligne pivot d'un CSV de traduction :

row["src_hash"] = cell_hash(text)
row[f"hash_{src_lang}"] = row["src_hash"]   # commentaire : « hash_{src_lang} == src_hash par construction »

Pour la langue pivot (fr), hash_fr doit donc toujours egaler src_hash — et les deux egaler cell_hash(source notebook).

Aucun check ne le valide. scripts/translation/check_translation_sync.py boucle sur TARGET_LANGS = ["en","es","ar","fa","zh","ru","pt"] — le pivot fr n'y est pas, avec le commentaire explicite « sa coherence est deja verifiee par SRC_DRIFT ci-dessus -> on le skippe ». Or SRC_DRIFT compare csv src_hash a la source notebook : il ne dit rien de hash_fr. Le champ hash_fr d'une ligne pivot n'est donc lu par personne.

Mesure (2026-09-24, lane myia-po-2026:CoursIA)

Sur la PR #17649, un resync manuel de la ligne cell-70d7edfe (translations/partner-course-quant-trading/partner-course.csv) avait ecrit src_hash=b57efbe05e2c9891 avec hash_fr=cc6406788d3ad741 — et cc6406788d3ad741 est le hash du text_en de la meme ligne. Les deux colonnes de hash etaient decalees d'un cran ; hash_en ne correspondait plus non plus a text_en.

Recalcul avec la recette du depot (cell_hash = sha256(normalize(texte))[:16], normalize = rstrip par ligne + strip des \n aux bornes) :

Champ	Declare	Recalcule	Verdict
src_hash	b57efbe05e2c9891	cell_hash(source notebook) = b57efbe05e2c9891	coherent
hash_fr	cc6406788d3ad741	cell_hash(text_fr) = b57efbe05e2c9891	incoherent (= hash du text_en)
hash_en	01206fb6375c62cf	cell_hash(text_en) = cc6406788d3ad741	incoherent

Tout le CI de traduction etait vert sur cette ligne : Translation drift (read-only) success et Translation hot-drift (base vs PR, advisory) success. Le seul champ faux est precisement celui qu'aucun check ne lit.

Sur les 3 autres lignes du meme cell_id (le CSV en porte 4 pour cell-70d7edfe), l'invariant etait respecte — le defaut est donc bien localise et non un artefact de lecture.

Ce que ce trou permet

Le garde translation-guard (#10332) impose un dual-key translation-override + [TRANSLATION-OVERRIDE] <motif> pour tout resync manuel, presente comme la « sortie auditable ». Mais l'auditabilité porte sur la declaration, pas sur la validite : un resync incoherent peut etre declare legitime et passer. Le commentaire d'override du precedent #17491 verifie a la main les hashes des trois cotes (hash declare / hash du champ / hash de la source) — c'est une discipline humaine, non outillee.

Proposition

Ajouter au checker une verification de l'invariant pivot, avec le meme traitement que les autres anomalies (JSON + exit code, non-bloquant en --check) :

• pour chaque ligne, si hash_{src_lang} est non vide, exiger hash_{src_lang} == src_hash ; sinon verdict PIVOT_HASH_MISMATCH avec les deux valeurs ;
• couvrir aussi le cas ou hash_{src_lang} et src_hash sont non vides mais differents de cell_hash(text_{src_lang}) ;
• test unitaire avec une fixture portant les deux formes (conforme + decalee d'un cran, comme ci-dessus).

Note de portee : ceci ne remplace pas la verification du contenu traduit (hash_en vs cell_hash(text_en)), qui se heurte au fait que les notebooks cibles sont absents du depot — c'est le sens du verdict MISSING_LANG existant. L'invariant pivot, lui, est entierement verifiable hors ligne.

Contexte lie

• translation-sync.yml n'a plus tourne depuis le 2026-08-14 (dernier run push/main, success) : la voie automatique est de fait morte, ce qui multiplie les resyncs manuels et donc l'exposition a ce trou.
• Voisins : translation-guard : aucun mecanisme d'arbitrage ecrit — 2 overrides legitimes ce cycle passes par un bypass admin non auditable #10332 (garde + dual-key), [#1650] Infra de synchronisation traduction — CSV par série (1 ligne/cellule × langues) + CI drift-flag + resync manuelle via moteur Argumentum #4957 (T2 drift), translations: 7 cellules SRC_DRIFT héritées de base — hot-subset ratchet rouge sur toute PR fusionnant main (#15216/#15253/#15136 sans resync) #15323 / fix(translations,#16891): resync miroir iit/iit.csv — ligne 18426 propage encore l assertion contredite par la sortie 5/6 #17445 (precedents de resync per-cell).

See #4957

[jsboige]

Livraison : PR #17685 — verdict PIVOT_HASH_MISMATCH dans check_translation_sync.py (check row-interne, placé avant le chargement du notebook, lenient sur hash pivot vide) + 8 tests dont un roundtrip T1→T2 bornant les faux positifs (55/55 verts).

Passage sur les CSV réels : 90 lignes signalées — 3 de la forme décalée (hash_fr != src_hash, la forme de l'incident fondateur), 87 de la forme « colonne text_fr stale vs hash déclaré ». Impact CI nul : translation-drift.yml invoque avec --check (non-bloquant) — les 90 lignes remontent en advisory. Le tri/resync de ces 90 lignes est un backlog de données par famille (hors scope tooling).

[jsboige]

[CLAIMED] lane myia-po-2026:CoursIA-2 -- paths: scripts/translation/check_translation_sync.py, scripts/tests/test_check_translation_sync.py -- narrow 1:1 strict

[jsboige]

[INFO] lane myia-po-2026:CoursIA-2 -- grain rendu par #17685 (myia-po-2026:CoursIA, livraison 2026-09-24T14:58Z, 8 tests pivot, 55/55 verts). Tell c.1356 ★★★ strict fondateur : pas de REDELIVRE. Geste posé : rerun du job flake #16288 sur #17685, commentaire first-hand sur la reproduction locale 48/48 verts (PR innocente). Cause systémique partagée avec 6+ autres PRs, signal au coordinateur dashboard.

[RELEASED] lane myia-po-2026:CoursIA-2 -- paths: scripts/translation/check_translation_sync.py, scripts/tests/test_check_translation_sync.py