Move effect build order is incorrect (fixes #1663)

[Atakan-24]

Fixes #1663

The bug

#1637 replaced the per-row MoveEffect.objects.get(pk=...) / try/except lookup
with a single precomputed set:

existing_effect_ids = set(MoveEffect.objects.values_list("pk", flat=True))

That is the right idea, but the line was placed after the Move builder and
immediately before the MoveChange block. So the validity guard only ever reached
MoveChange.move_effect_id. Move.move_effect_id kept assigning
int(info[10]) unchecked and could therefore point at a MoveEffect row that was
never built — a dangling foreign key, which is what #1663 reports.

The fix

• Compute existing_effect_ids where it becomes valid, directly after
  build_generic((MoveEffect,), "move_effects.csv", ...), so every later builder
  can filter against it instead of only the last one.
• Add resolve_existing_id(raw_value, existing_ids) — one place that decides
  what a CSV foreign-key column means: empty column → None, id that was never
  built → None, otherwise the integer. Both builders call it, so the two cannot
  drift apart again.
• Extract the two row builders into module-level move_from_csv_row() and
  move_change_from_csv_row(). They were inline closures reassigned to the same
  csv_record_to_objects name, which meant no test could reach them. They are
  now importable and tested directly.

The column positions differ between the two files and that is exactly the trap:
moves.csv has effect_id at index 10, move_changelog.csv at index 8, because
MoveChange has no priority or target field and those two columns are skipped.

Tests

Added to the existing pokemon_v2/test_models.py, so they run under the project's
own runner (uv run manage.py test, per the Makefile) with no new tooling:

1. resolve_existing_id — built id, unbuilt id, empty column.
2. Positions are checked against the CSV header, not hardcoded. The test builds
   a synthetic row, locates effect_id / effect_chance by header name, and asserts
   the builder picked up the same column. This is the class of bug that caused Move effect build order is incorrect #1663,
   so it is worth pinning rather than trusting the index.
3. Every real row of moves.csv and move_changelog.csv goes through the
   production builder, compared against an expectation derived independently by
   column name — and the test fails if no row resolves to a built effect, so it
   cannot pass by filtering everything to None.

No behaviour change beyond the fix: valid effect references are still assigned,
move_effect_chance is untouched, and only ids that were never built become None.

---

Disclosure: the change was prepared with an automated pipeline of mine (evaluator →
plan review → implementation → independent review → adversarial review), then
stopped so a human opens, reads and submits it. I have read the diff and the tests
myself and I stand behind them; the CI run on this PR is green on Python 3.10–3.14
plus static checks. Happy to adjust scope or split anything out if you would
rather see it smaller.

[FallenDeity]

@Atakan-24 wasnt this a similar pr #1669 did that not fix this issue

[Atakan-24]

You're right — #1669 fixed the column-index bug and closed the issue. This PR was prepared on Sept 4, before #1669 landed on Sept 8, and I opened it without re-checking first; sorry for the noise.

The only thing still missing on master is test coverage for that code path, which #1669 mentioned didn't exist. If that's useful I can strip this PR down to just the regression tests — they locate the effect_id/effect_chance columns by header name rather than hardcoded position, and check every real CSV row against an independently derived expectation, so the same class of bug can't come back silently. Otherwise I'll close it.