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/app/models/plan.py

@@ -123,6 +123,7 @@ class Age4ProjectionResponse(BaseModel):
     projected_left_at_b4: int
     savable_after_b4: int
     expiring_at_b4: int
+    savable_cap_at_b4: int
 
 
 class PlanProposalResponse(BaseModel):
@@ -218,6 +219,7 @@ class PlanProposalResponse(BaseModel):
                     projected_left_at_b4=p.projected_left_at_b4,
                     savable_after_b4=p.savable_after_b4,
                     expiring_at_b4=p.expiring_at_b4,
+                    savable_cap_at_b4=p.savable_cap_at_b4,
                 )
                 for p in proposal.age4_projections
             ],
@@ -231,9 +233,12 @@ class PlanProposalResponse(BaseModel):
 
 class ProposedDayApplyItem(BaseModel):
     """One day to persist. Same shape as `ProposedDayResponse` minus the
-    explain-only `wish_id`/`reason` (harmless if a caller sends them anyway —
-    a frontend can hand back `ProposedDayResponse` entries from `/propose`
-    verbatim; extra fields are ignored).
+    explain-only `reason` (harmless if a caller sends it anyway — a frontend
+    can hand back `ProposedDayResponse` entries from `/propose` verbatim;
+    extra fields are ignored). `wish_id` DOES carry persistence meaning here
+    (unlike `reason`): it links the persisted row back to the wish that
+    produced it, so a client handing back a `/propose` day verbatim gets that
+    attribution persisted for free.
 
     `day_type` additionally accepts 'free' (an automatic weekend/red-day
     entry from a proposal) purely so a client doesn't have to filter those
@@ -246,6 +251,8 @@ class ProposedDayApplyItem(BaseModel):
     child_id: UUID
     day_type: str = Field(pattern="^(sjukpenning|lagsta|vacation|free)$")
     is_dubbeldag: bool = False
+    wish_id: UUID | None = None
+    is_pinned: bool = False
 
     def to_domain(self) -> ProposedDayInput:
         return ProposedDayInput(
@@ -254,6 +261,8 @@ class ProposedDayApplyItem(BaseModel):
             child_id=self.child_id,
             day_type=self.day_type,
             is_dubbeldag=self.is_dubbeldag,
+            wish_id=self.wish_id,
+            is_pinned=self.is_pinned,
         )