feat(virtues): scaffold i18n columns (#218)

[jsboige]

Summary

Scaffolds multilingual support for Virtues (issue #218) by adding empty _en/_ru/_pt columns to the CSV and matching Optional() ClassMap entries on the entity. No data is populated — this is a schema-only change so the DatasetUpdater translation pipeline (unblocked by #183/PR #210) can write multilingual fields without further code changes.

Scope

• Cards/Fallacies/Argumentum Virtues - Taxonomy.csv — header + 222 data rows get 21 trailing empty fields (7 cols × 3 langs):
  family_en, subfamily_en, subsubfamily_en, title_en, description_en, remark_en, link_en
  • same for _ru + same for _pt.
• Entities/ArgumentVirtue.cs — 21 new string properties (FamilyEn…LinkPt, Ru, Pt) + 21 .Name("…").Optional() ClassMap entries. FR fields stay non-optional.

What this is NOT

• No translations written. Data population is the follow-up (will use PR chore(dataset-updater): migrate to GPT-5.x models #222's tiered model config once merged + validated).
• No LocalizationConfig changes. The Virtues scaffold on the rendering side was already merged in bug: non-FR PDFs contain French text — translations not applied #216 (was no-op until these CSV columns existed).

Why

Complements the #216 rendering-side scaffold so the full i18n chain (CSV → entity → localization → templates) is now wired. Once PR #222's model migration lands and DatasetUpdaterRootConfig.VirtuesTaxonomy.Enabled = true, Virtues become fully translatable without touching code.

Test plan

• dotnet build — no errors, only pre-existing warnings
• dotnet test — 88 pass / 0 fail / 1 skip (Freeplane GUI, expected)
• CSV reloads cleanly in CsvHelper (import via Import-Csv reports 223 rows × 38 columns, was 17)
• Runtime smoke: follow-up after merge, run pipeline stage that loads Virtues and confirm no warnings about unmapped columns

Refs #218
Depends on: none (scaffold only, no runtime coupling to #222)

🤖 Generated with Claude Code

[jsboige]

Post-commit blind-spot audit — fix added

Tracing CsvType references during a downstream audit revealed that the Virtues CSV is actually loaded via Entities/Virtue.cs (singular, CsvType = typeof(Virtue) in AssetConverterConfig.cs:79), NOT ArgumentVirtue.cs which the initial commit scaffolded.

ArgumentVirtue is referenced only by MappingProfile.cs (an AutoMapper CreateMap<ArgumentVirtue, Fallacy>() definition that is never actually invoked anywhere in the codebase) — i.e., dead code.

Commit e904dcfe extends the _en/_ru/_pt scaffold to Virtue.cs (21 properties + matching .Optional() ClassMap entries). The original ArgumentVirtue scaffold is kept for symmetry — AutoMapper's .ReverseMap() would break otherwise if that code path is ever re-enabled.

Without this fix, activating DatasetUpdater.VirtuesTaxonomy.Enabled = true would run fine (DatasetUpdater works with dynamic DataTable columns, not via Virtue entity), but the downstream pipeline stage that loads Virtues for PDF rendering would silently drop the translated data.

Build + 88 tests still pass on the new HEAD.

[clusterManager-Myia]

Post-hoc review — PR #223 feat(virtues): scaffold i18n columns (#218)

Verdict: ✅ LGTM — with a note on dead code

Well-executed scaffold for Virtues i18n. CSV gets 21 new empty columns (7 fields × 3 languages), entity gets matching Optional() ClassMap entries.

Concerns:

• Dead code: As noted in PR fix(virtues): extend i18n scaffold to Virtue entity (follow-up to #223) #229's description, ArgumentVirtue entity is dead code — the actual runtime entity is Virtue. This PR scaffolded on the wrong entity, but fix(virtues): extend i18n scaffold to Virtue entity (follow-up to #223) #229 fixes it. No harm done since the CSV columns are the real deliverable.
• All new columns are Optional() which is correct for a scaffold — no data to parse yet.
• The line ending normalization in the closing brace is a minor style nit.

CSV structure is consistent with the Fallacies i18n pattern. No data populated, no regressions.