refactor(person): single source of truth for generation bounds (#689)

Markus flagged the 0/10 range was duplicated across five sites (DB
CHECK, both importers, DTO @Min/@Max, dropdown range). New
PersonGeneration.MIN_GENERATION / MAX_GENERATION constants are now
the canonical Java source; the DTO annotations and both importer
guards reference them. The V70 SQL CHECK comment now points at the
Java constants so future widening updates one Java class plus one
SQL literal (Flyway forbids rewriting the migration in place).

Refs #689

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

backend/src/main/resources/db/migration/V70__add_generation_to_persons.sql

@@ -10,11 +10,13 @@
 
 ALTER TABLE persons ADD COLUMN generation SMALLINT;
 
--- Allowlist of valid generation indices. The upper bound is intentionally
--- loose — current data tops out at G 5, but a future G 6 → G 10 widening
--- needs no migration. A G −1 ancestor would require a separate one-shot
--- shift migration (out of scope here; the layout's normalise step already
--- handles negative seeds at render time).
+-- Allowlist of valid generation indices. The 0..10 bounds mirror
+-- PersonGeneration.MIN_GENERATION / MAX_GENERATION in Java — keep the
+-- two in sync (the DTO @Min/@Max and both importer range guards read from
+-- those Java constants). Current data tops out at G 5, but a future G 6 →
+-- G 10 widening needs no migration. A G −1 ancestor would require a
+-- separate one-shot shift migration (out of scope here; the layout's
+-- normalise step already handles negative seeds at render time).
 ALTER TABLE persons ADD CONSTRAINT chk_generation_range
     CHECK (generation IS NULL OR generation BETWEEN 0 AND 10);