Fix(translation): --update --full avec input large absorbe le corpus dans chaque CSV de serie #21514

Part of #1650

Constat

extract_cells_to_csv.py en mode --update --full append le corpus entier a un CSV de serie quand l'input est large. La branche T1_MODE=full de .github/workflows/translation-sync.yml passe exactement cette forme a chacun des 36 CSV :

python scripts/translation/extract_cells_to_csv.py "MyIA.AI.Notebooks" --update "$csv" --full --repo-root .

Mesure (2026-10-20, main a8589d7b01)

Sur une copie hors depot de translations/compression/compression.csv (31 lignes, 1 carnet) :

rows 31 -> 49978   rc 0   28.2 s
OK (--update --full) : 6 ligne(s) rafraichie(s), 56 deja in-sync,
                       49947 ajoutee(s), 0 orpheline(s) potentielle(s),
                       0 ligne(s) d'autres notebooks preservees

49 947 lignes ajoutees a un CSV de 31. Le meme appel, applique aux 36 CSV, produirait un corpus de CSV ou chaque serie contient tout le depot.

Mecanisme (lu, pas suppose)

1. main() (scripts/translation/extract_cells_to_csv.py, ~l.462-491) : quand --full + --update, il charge le CSV, calcule les ref_dirs (dossier parent de chaque carnet reference) et etend existing_inputs avec ces repertoires --

   existing_inputs = list(existing_inputs)  # freeze
   for rd in ref_dirs:
       ...
       existing_inputs.append(abs_rd)

   Il n'en retire jamais l'input CLI. Le commentaire dit « Les ref_dirs serviront de bornes de scan » ; un input large les annule.
2. update_existing_csv (~l.300-306) : toute ligne fraiche dont la cle (notebook, cell_id) est absente de l'index est appendue inconditionnellement :

   else:
       existing_rows.append(fresh)
       appended += 1

   L'append est correct pour combler un carnet neuf de la serie ; il devient une absorption du corpus quand le scan n'est pas borne.

Portee de l'impact

• Aujourd'hui : la branche full est un workflow_dispatch (mode par defaut incremental), donc le defaut est latent, pas en production. Declenche une fois avec mode=full, il committe 36 CSV de ~50 000 lignes.
• Il n'affecte pas l'idempotence : mesuree en deux passes avec input exact, 36/36 CSV sont idempotents (test(translation,#1650): rejouer T1 --update sur les 36 CSV du corpus -- corroborer l'idempotence hors du seul CSV livre #20458, commentaire du 2026-10-20).

Correction envisagee (a arbitrer)

Deux formes possibles, a trancher par la lane qui prendra le grain :

1. Borner le scan en mode --full : ne garder que les ref_dirs (l'input CLI sert alors seulement en mode incremental). C'est ce que le commentaire du code annonce deja.
2. Garder l'input mais ne pas appender hors perimetre : n'appendre une ligne fraiche que si son carnet appartient a un ref_dir du CSV. Plus conservateur, laisse l'input servir a rafraichir des carnets cites hors serie.

La (2) me parait la plus sure -- elle preserve le comportement incremental et rend l'append dependant d'une borne explicite -- mais c'est un choix de perimetre, pas une evidence.

Acceptance

• un appel --update --full avec input large sur un CSV de serie ne fait pas croitre le CSV au-dela des carnets de sa serie (test dedie qui assert le nombre de lignes) ;
• la branche T1_MODE=full du workflow passe une invocation qui ne peut pas absorber le corpus ;
• le test existant de scripts/translation/tests/ couvre les deux formes (input borne / input large) ;
• aucune reecriture des 36 CSV n'est committable sans arbitrage : le corpus actuel est sain pour l'idempotence, il n'y a pas de dette a resorber cote CSV.

Sans parent : le parent doctrinal est l'EPIC i18n #1650, cite en tete ; ce defaut est ne de la mesure de #20458, qui est le vrai lieu de provenance.