Give every year of a repeating period its own row

A repeating period was a single row that the planner expanded into one
window per year at read time, so no year had anywhere to differ from the
others. Editing one year rewrote them all, and removing a year in the
middle had to split the wish in two. Neither survives contact with the
thing this app is for: Easter moves, and the cheapest week is not the
same week every year.

Each year is now its own row, linked by a series id. Editing one year
touches one row; editing the series re-projects the rest from it.
Removing a year is one delete. The weekday snap is worked out once, when
the rows are made, and stored, so a row now says what it means rather
than being re-derived on every read. Recurrence stops being a stored
field and becomes what it always was in practice — an instruction at
create and update time; whether a period repeats is whether it belongs
to a series.

Migration 004 rebuilds the table and expands the existing rows, keeping
each original row as its first year so the days already planned against
it still point somewhere. A Feb 29 anchor recurring into a common year
used to raise out of the allocator; it clamps now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ei7gCZzdd751uZtPzb1Pep

backend/tests/unit/test_services/test_allocation_input_loader.py

@@ -284,7 +284,6 @@ class TestAllocationInputLoader:
                 window_end_month=10,
                 window_end_day=7,
                 target_weeks=1,
-                recurrence="once",
                 first_year=2027,
                 last_year=None,
                 priority=1,
@@ -579,9 +578,12 @@ class TestAllocationInputLoader:
         planned_leave_repo: SQLitePlannedLeaveRepository,
         leave_wish_repo: SQLiteLeaveWishRepository,
     ) -> None:
-        """A wish with a far-out `last_year` and no children yet (so there's
-        no age-12 hard cap to save it) can still in principle push the
-        horizon past even a ~30-year cache. Rather than silently falling
+        """A wish row anchored in a far-out year, with no children yet (so
+        there's no age-12 hard cap to save it), can still in principle push
+        the horizon past even a ~30-year cache. `LeaveWishService` clamps a
+        materialised series to the cached range, but a row can reach the DB
+        another way (a hand-written import, an older client, this test's
+        direct repo write), so the loader must still defend itself. Rather than silently falling
         back to the live `holidays` library (the original bug) or silently
         clamping the horizon (which would contradict the §6 decision to plan
         past B4 and show the squeeze), the loader must raise a
@@ -604,9 +606,8 @@ class TestAllocationInputLoader:
                 window_end_month=6,
                 window_end_day=30,
                 target_weeks=4,
-                recurrence="yearly",
-                first_year=2027,
-                last_year=2200,
+                first_year=2200,
+                last_year=None,
                 priority=1,
                 parent_mode="either",
                 parent_personal_data_uuid=None,