test(mindmap): #204 MindMap localization ordering contract + 8-lang gap

[jsboige]

What

Secondaire #204 — MindMap localization fragile zones. Pins the two genuine gaps in the DocumentLocalization localization mechanism that the existing MmGeneratorTests coverage misses. Additive only (1 new file, 0 prod code, 0 existing test touched).

Why these two zones

The pipeline localizes each Fallacy mind map expression by running DocumentLocalization.DoReflectionTranslate over the LocalizationConfig.MindMapLocalization entries, which calls DoStaticConversions — a naive template.Replace(sourceText, destText) per language, with no token-boundary awareness. That is the same substring-replacement fragility class already pinned for card-set mapping (#477) and the CSV contract (#488), but never pinned for MindMap localization.

The existing theory MindMapLocalization_ShouldTranslateAllFallacyExpressions only exercises the happy path for en/ru/pt, where each default expression carries exactly one family keyword — so it never hits the partial-match interaction the config itself warns about.

1. The ordering contract (headline)

AssetConverterConfig.cs family-hierarchy DocumentLocalization carries this comment:

Order: most specific first (Soussousfamille > SousFamille > Famille) to avoid partial matches

That comment exists because Famille is a substring of SousFamille: if the less-specific conversion ran first, a template mentioning SousFamille would be corrupted into SousFamily before the SousFamille conversion could fire. No test pinned this contract.

FamilyHierarchy_LocalizationOrderingPreventsPartialMatchContamination (Theory, 7 langs) runs the real family-hierarchy entry — located by TargetProperties.Contains(FamilleExpression), not by a fragile list index — on a crafted template carrying all three keywords at once:

{item.Soussousfamille} / {item.SousFamille} / {item.Famille}

and asserts each resolves to its distinct localized property, plus .NotContain("SousFamily") — the direct corruption signature of a broken ordering.

2. The 8-language release scope

The existing theory covers only en/ru/pt. The release targets 8 languages and the config declares 7 target langs (en/ru/pt/es/ar/fa/zh). FallacyExpressions_LocalizeForGapLanguages_es_ar_fa_zh (Theory, 4 langs) closes the gap — applying all real localizations to a fresh FallacyMindMapDocumentConfig and asserting every text + family expression resolves for es/ar/fa/zh. A dropped conversion (someone trims the config back to en/ru/pt) surfaces here.

What I deliberately did NOT do

• No Virtue localization test. I investigated it: the config's Virtue entry converts Vertus→Virtues, but the VirtueMindMapDocumentConfig.TitleExpression default is {item.Text} — it does not contain Vertus, so the conversion is a no-op on the default. A test would have to set TitleExpression = "Vertus" synthetically, which characterizes a config/data inconsistency rather than a real fragile path. Dropped to keep the suite honest. (Side note: the Virtue entry also only declares 4 langs en/ru/pt/es vs the 7 elsewhere — a real data gap, but out of scope for a test-only PR; flagging here for a future data PR.)
• No modification to any existing test or production code.

Verification

• New tests: 11/11 green (7 ordering rows + 4 gap-lang rows).
• Full suite: 270 passed / 0 failed / 5 skipped (baseline 259 + 11; the 5 skips are the usual Playwright/Freeplane interactive tests).
• No production code changed; no config/CSV/templates touched.

Constraints held

0 merges / 0 regen / 0 API runs. Additive only. Release gate intact. Worker po-2024 — signaling, not declaring PASS.

🤖 Worker po-2024