Link planned days to their wish, fix the age-4 cap, drop the planning goal

Three changes that together unblock treating a calendar period as one
editable object.

Migration 008 adds `planned_leave_day.wish_id` (nullable, ON DELETE SET NULL)
so a persisted day knows which `leave_wish` produced it, `is_pinned` to mark a
day the user hand-edited, and `leave_wish.target_days` so a period drawn on a
calendar need not be a whole number of weeks. Apply-time identity still keys on
day_type/is_dubbeldag only, so a wish_id-only difference is a metadata update
rather than a collision.

The age-4 savable ceiling was applying the per-child figure of 96 to each
parent's pool, modelling a two-parent family as able to save 192 days past the
child's fourth birthday. `resolve_age4_savable_cap` is now the single place
that decides 48 (couple with two parents) versus 96 (everyone else), and both
AnalyticsService and the allocator read it.

Migration 009 drops `workspace.planning_goal` and `leave_wish.goal_override`.
The allocator's tier-3 policy collapses to one rule; `salary_type` still
branches, since that reflects what a vacation day actually costs a parent
rather than a user preference.

backend/migrations/versions/008_add_wish_link_and_target_days.py

@@ -0,0 +1,68 @@
+"""Link planned_leave_day back to the wish that produced it; add pin + day-granular target.
+
+Persisted leave days currently have no link back to the `leave_wish` that
+produced them: the allocator's `ProposedDay` carries `wish_id`, but it was
+deliberately stripped at persist time. That makes it impossible for the UI to
+click a multi-day band on a calendar and edit it as one period — the entire
+point of the UX rework this migration is the keystone for.
+
+Three additive, independently-nullable/defaulted changes (no backfill
+possible or needed — every existing row predates this link):
+
+1. `planned_leave_day.wish_id` — which wish produced this day. NULL = ad-hoc
+   / legacy / unattributable (e.g. a day added by hand, or persisted before
+   this column existed). `ON DELETE SET NULL` so deleting a wish later never
+   cascades into deleting the days it already funded — it only orphans them
+   back to "ad-hoc", matching the nullable semantics.
+2. `planned_leave_day.is_pinned` — marks a day the user hand-edited so a
+   later allocator pass knows not to retype it. This migration only adds the
+   column and carries it through the read/write path; the allocator itself
+   does not yet honor it (a follow-up task wires that up).
+3. `leave_wish.target_days` — a calendar-drawn period is not a whole number
+   of weeks. NULL (the default for every existing row) falls back to
+   `target_weeks * 7` via `LeaveWish.target_span_days()`.
+
+Revision ID: 008
+Revises: 007
+Create Date: 2026-09-15
+"""
+
+from __future__ import annotations
+
+from alembic import op
+
+revision: str = "008"
+down_revision: str | None = "007"
+branch_labels: str | None = None
+depends_on: str | None = None
+
+_UPGRADE_SQL = """
+ALTER TABLE planned_leave_day ADD COLUMN wish_id TEXT
+    REFERENCES leave_wish(id) ON DELETE SET NULL;
+
+ALTER TABLE planned_leave_day ADD COLUMN is_pinned INTEGER NOT NULL DEFAULT 0;
+
+ALTER TABLE leave_wish ADD COLUMN target_days INTEGER;
+"""
+
+_DOWNGRADE_SQL = """
+ALTER TABLE leave_wish DROP COLUMN target_days;
+
+ALTER TABLE planned_leave_day DROP COLUMN is_pinned;
+
+ALTER TABLE planned_leave_day DROP COLUMN wish_id;
+"""
+
+
+def upgrade() -> None:
+    from sqlalchemy import text
+
+    for stmt in [s.strip() for s in _UPGRADE_SQL.split(";") if s.strip()]:
+        op.execute(text(stmt))
+
+
+def downgrade() -> None:
+    from sqlalchemy import text
+
+    for stmt in [s.strip() for s in _DOWNGRADE_SQL.split(";") if s.strip()]:
+        op.execute(text(stmt))

backend/migrations/versions/009_drop_planning_goal.py

@@ -0,0 +1,50 @@
+"""Drop workspace.planning_goal and leave_wish.goal_override.
+
+Product decision: there is only one sensible allocation objective — maximise
+the value extracted from parental-leave days plus vacation days. Exposing
+`max_time` / `max_money` / `balanced` as a user-facing setting made the
+planner's behaviour unpredictable without making it more useful. The engine
+now always applies what used to be the `max_money` policy; the `goal`
+concept (and the ability to override it per-wish) is removed entirely.
+
+Revision ID: 009
+Revises: 008
+Create Date: 2026-09-15
+"""
+
+from __future__ import annotations
+
+from alembic import op
+
+revision: str = "009"
+down_revision: str | None = "008"
+branch_labels: str | None = None
+depends_on: str | None = None
+
+_UPGRADE_SQL = """
+ALTER TABLE workspace DROP COLUMN planning_goal;
+
+ALTER TABLE leave_wish DROP COLUMN goal_override;
+"""
+
+_DOWNGRADE_SQL = """
+ALTER TABLE workspace ADD COLUMN planning_goal TEXT NOT NULL DEFAULT 'balanced'
+    CHECK (planning_goal IN ('max_time','max_money','balanced'));
+
+ALTER TABLE leave_wish ADD COLUMN goal_override TEXT
+    CHECK (goal_override IS NULL OR goal_override IN ('max_time','max_money','balanced'));
+"""
+
+
+def upgrade() -> None:
+    from sqlalchemy import text
+
+    for stmt in [s.strip() for s in _UPGRADE_SQL.split(";") if s.strip()]:
+        op.execute(text(stmt))
+
+
+def downgrade() -> None:
+    from sqlalchemy import text
+
+    for stmt in [s.strip() for s in _DOWNGRADE_SQL.split(";") if s.strip()]:
+        op.execute(text(stmt))