refactor: remove retired data format support

docs/architecture.md

@@ -275,11 +275,11 @@ distinct secondary stats from those separate pools.
 Every active Skill Chip definition belongs exclusively to one active
 specialization ability through `skill_chip_sets.specialization_ability_id`.
 An ability has capacity for exactly three active definitions. The save and
-restore actions enforce that capacity, while legacy rows may remain nullable
-until they are edited. A specialization focus is builder-ready only when each
-of its three assigned abilities has all three active Skill Chip definitions.
-Skill Chip mutations refresh readiness for focuses that reference both the
-previous and resulting ability.
+restore actions enforce that capacity, and the foreign key is required for
+every row. A specialization focus is builder-ready only when each of its three
+assigned abilities has all three active Skill Chip definitions. Skill Chip
+mutations refresh readiness for focuses that reference both the previous and
+resulting ability.
 
 Both set-bonus progression systems use the number of equipped High-end chips as
 the interpolation step. For `h` High-end chips, where `h` is zero through
@@ -308,10 +308,11 @@ Specialization proposal workflow.
 
 Loadout schema version 2 stores one focus, the selected rank for each tree node,
 nine Skill Chips, conditional-effect modes, and encounter assumptions. Each of
-the three focus abilities owns three chip positions. Version 1 migration keeps
-the three old chips in `specialization.unassignedChips`; the builder requires
-the user to place them under compatible abilities before it reports a complete
-calculation.
+the three focus abilities owns three chip positions. Runtime readers accept
+only the exact version 2 structure. Local drafts, saved builds, shared builds,
+and calibration snapshots reject older or partial structures instead of
+repairing them. Database migration removes obsolete snapshots after the
+required environment backup.
 
 # Versioned combat calculations