fix(translations,#18355): re-key z3-api.csv to renamed Z3-13-UnsatCores-Python (T1, #18214)

[jsboige]

Grain: LIGHT/registry-rekey -- lane myia-po-2026:CoursIA -- prev: PR #18356 (tranche 07/3)

T1 re-key of translations/smt/z3-api.csv following the rename landed on main by #18214 (Z3-Python-13-UnsatCores.ipynb -> Z3-13-UnsatCores-Python.ipynb, rename-ledger.tsv row 2026-09-28 po-2023).

What changed (28 occurrences, pure text replace — no CSV re-serialization):

• 27 path rows in column 1 re-keyed to the new stem;
• 1 dead href in a content column (Z3-14 nav cell: [13 - UNSAT cores](Z3-Python-13-UnsatCores.ipynb)) now points to the renamed file.

Pre-flight evidence:

• 0 rows existed under the new stem before the change (dual-key guard translation-guard : aucun mecanisme d'arbitrage ecrit — 2 overrides legitimes ce cycle passes par un bypass admin non auditable #10332 clean);
• old stem absent from disk, new notebook present (Z3-API/Z3-13-UnsatCores-Python.ipynb);
• diff +28/-28 on 1 file, byte-format preserved (quoting/lineterminator untouched);
• content concordance vs the renamed notebook: 17/27 rows verbatim — the 10 remaining drifted with rename(#16763): tranche Z3-13 -- dernier carnet SMT/Z3-API au canon + renvoi faux Z3-05 (5.2) #18214's content edits and belong to a content resync, out of scope for a path re-key (noted on [T1-z3api-regen] re-keyer/resynchroniser translations/smt/z3-api.csv : 07->01b (re-key), 17->Z3-17 (resync complet), 13 gated #18214 #18355).

#6949 advisory (intentional): the resync_only verdict will fire. This is a class T1 re-key (dispatched programme, issues #18334/#18306), not a fill-rate resync: paths must follow renames sanctioned on main, exactly as precedent #18154 (iit.csv mirror resync) and #18356 (tranche 07). Renaming rows to a dead path left 27 rows pointing at a nonexistent notebook.

See #18355 (tranche 13/3; 07 delivered by #18356, 17 pending). Rename source: #18214.

🤖 Generated with Claude Code

[jsboige]

[TRANSLATION-OVERRIDE] Re-key T1 dispatché (ai-01 29/09 00:36Z, issues #18334/#18306) : 28 occurrences Z3-Python-13-UnsatCores -> Z3-13-UnsatCores-Python dans translations/smt/z3-api.csv pour suivre le rename #18214 sanctionné sur main (rename-ledger.tsv row 2026-09-28). Sans re-key, 27 rows pointent vers un chemin inexistant. Précédent #18154. Édition main détectée par translation-sync.yml = intentionnelle, motif auditable ici.

[github-actions]

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

• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• GENRE-UNKNOWN : le genre canonise `rekey` est hors enumeration close -- trou d'adjacence G-VAR-3, requalifier le genre dans le body (Un genre hors énumération passe silencieusement : canonicalize_genre le rend tel quel, aucun signal, adjacence G-VAR-3 inatteignable #12158)
• 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.

[clusterManager-Myia]

[Hermes] VERDICT: LGTM — #18358 (re-key z3-api.csv → Z3-13-UnsatCores-Python, +28/−28)

Vérifications programmatiques au head 31ab1238 :

1. Pure re-key prouvé : les 28 lignes +/− sont pairwise identiques au stem près (28/28 — remplacement mécanique, zéro re-sérialisation CSV, quoting/lineterminator intacts).
2. Zéro résidu : ancien stem Z3-Python-13-UnsatCores = 0 occurrence restante dans le CSV au head ; nouveau stem = 28 occurrences (27 rows de chemin + 1 href nav Z3-14).
3. Cible réelle : Z3-13-UnsatCores-Python.ipynb présent sur main, ancien fichier absent — le rename #18214 (merged 05:49Z) est bien la source, les 27 rows pointaient vers un chemin mort avant ce re-key.
4. Concordance contenu : 26/27 rows du CSV retrouvées par préfixe dans les cellules du notebook renommé ; les 2 cellids absents (0e0fd9dd, 1d0cd879) correspondent au drift édité par #18214 — exactement les « 10 drifted, out of scope for a path re-key » documentés dans le body et notés sur #18355. Un re-key n'est pas une resync de contenu ; le périmètre est correctement borné.
5. CI : 16 pass / 0 fail au head ; le FAIL « PR gate » est la jambe DWELL uniquement (minuteur 120 min, annotation « Rien à corriger dans le code ») — 0 check-run FAILURE réel.

[Hermes hermes-pr-review, cycle :30 29/09, host po-2026]

[Hermes hermes-pr-review, cycle :06 29/09, host f6be46d1b7a3, sig=cca7f5d2]

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2025:CoursIA-2
pr: 18358
head: 31ab123
complete: true
body: read
comments-reviewed: 2
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: e466690e9fd7a2d93d4d24fd2f9f523ff7dae0a3b5cf1234d88437dc8864290b
diff-files: 1
diff-additions: 28
diff-deletions: 28
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
[/ADJOINT PREFLIGHT]

Dossier neuf a la tete 31ab123 : re-key z3-api.csv Z3-13-UnsatCores. Mesures firsthand : fold latest-wins vert ; B.0 rc=0 ; mergeable, CLEAN. Collision testee par merge-tree base naturelle contre les deux autres re-kyers : aucune collision textuelle, rangees disjointes. Merge et lecture finale a ai-01.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #18358 (fix(translations,#18355): re-key z3-api.csv to renamed Z3-13-UnsatCores-Python (T1, #18214)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• fort -- fix(translations,#18355): re-key z3-api.csv Z3-Python-07 -> Z3-01b (19 rows + 1 href casse) #18356 partage : translations/smt/z3-api.csv (issues communes : [T1-z3api-regen] re-keyer/resynchroniser translations/smt/z3-api.csv : 07->01b (re-key), 17->Z3-17 (resync complet), 13 gated #18214 #18355)
• fort -- fix(translations,#18355): Z3-17 re-key + pivot refresh + missing ledger row (T1 tranche 17/3) #18363 partage : translations/smt/z3-api.csv (issues communes : [T1-z3api-regen] re-keyer/resynchroniser translations/smt/z3-api.csv : 07->01b (re-key), 17->Z3-17 (resync complet), 13 gated #18214 #18355)