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/app/services/tips_service.py

@@ -481,20 +481,18 @@ async def _rule_wrap_red_days_with_vacation(ctx: TipsContext) -> Tip | None:
 
 
 def _concrete_windows_near_today(wish: LeaveWish, today: date) -> list[tuple[date, date]]:
-    """Concretize a recurring wish into the window(s) anchored near `today`.
+    """This wish's window, if it is anchored near `today` — else nothing.
 
-    Only a small neighbourhood of anchor years is considered (last year,
-    this year, next year) — enough to catch a window that started last
-    December and wraps into January (see LeaveWish.window_for_year) without
-    materialising the wish's entire multi-year horizon. Full expansion across
-    the whole horizon is the allocator's job (PLANNING_ENGINE_SPEC.md §3.2),
-    not the tips engine's.
+    One wish row is one year (see `app.entities.leave_wish`), so there is
+    nothing to concretize any more; the tips engine just ignores occurrences
+    far from today. The neighbourhood is last year / this year / next year —
+    "last year" is what catches a window that started last December and wraps
+    into January. Reasoning over the whole horizon is the allocator's job
+    (PLANNING_ENGINE_SPEC.md §3.2), not the tips engine's.
     """
-    windows = []
-    for year in (today.year - 1, today.year, today.year + 1):
-        if wish.applies_to_year(year):
-            windows.append(wish.window_for_year(year))
-    return windows
+    if wish.first_year not in (today.year - 1, today.year, today.year + 1):
+        return []
+    return [wish.window()]
 
 
 async def _rule_long_break_parent_swap(ctx: TipsContext) -> Tip | None: