Export: generate ModMap.lua from Mods.dat instead of hand-maintaining it

[jay9297]

Goal

src/Data/ModMap.lua says it on line 1: "This is currently made by hand but should be auto generated." Make the exporter generate it, removing one more hand-maintained file from the patch-update checklist.

⚠️ Constraint for AI agents

Writing the export script is agent-doable; running it requires a local PoE2 install + Windows extractor, which agents/CI don't have. The deliverable is the export script plus a verification path; the final regenerate-and-diff must be run by the maintainer (@jay9297). State this explicitly in the PR.

Background (read first)

• Read CLAUDE.md.
• src/Export/Scripts/mods.lua already generates the sibling files (ModItem.lua, ModFlask.lua, ModCharm.lua, ModJewel.lua, ModCorrupted.lua, …) from Mods.dat + stat descriptions, splitting by mod domain/generation type. Study how it selects rows and emits each output file — the map domain is the gap.
• Compare the structure of the hand-written src/Data/ModMap.lua against a generated sibling like src/Data/ModItem.lua: field order, spawn weights/tags, stat-order metadata. The generated output must keep the same consumer-facing structure (find the consumers by grepping ModMap across src/ first and list them in the PR).

What to build

1. Identify the data source. Determine which mod domain / generation types in Mods.dat correspond to PoE2 map (Waystone) affixes. Check how mods.lua filters domains today and what domain enum values exist (src/Export/Scripts/enums.lua exports modDomains). Document the finding in the script header.
2. Extend src/Export/Scripts/mods.lua (preferred over a new script, to reuse its describe/emit helpers) to also emit src/Data/ModMap.lua with the standard "This file is automatically generated, do not edit!" header.
3. Preserve consumer compatibility. Diff the script's output structure against the current hand-written file's structure (you can't run the exporter, but you CAN statically verify: the emit code paths you add must produce the same table shape the consumers read — show this mapping in the PR description, field by field).
4. Add a data check if practical: if there's an existing --tags data spec validating other Mod*.lua files' shape, extend it to cover ModMap.lua so a bad regeneration gets caught.

Acceptance criteria

• src/Export/Scripts/mods.lua contains the ModMap emission path, mirroring the style of the existing per-domain emitters.
• Consumers of data.modMap/ModMap (list them) are unchanged.
• docker compose run --rm busted-tests --tags data and the full suite pass (the committed ModMap.lua itself is NOT regenerated in this PR — content changes only after the maintainer runs the exporter).
• PR includes a "maintainer verification" section: run export, diff regenerated ModMap.lua against the hand-written one, and reconcile (hand-written entries missing from the export indicate a filter bug; investigate before accepting).

Out of scope

• Regenerating/committing the new ModMap.lua content (maintainer step).
• Touching other Mod*.lua outputs.