Separate user intent from planner output via day assertions

The calendar mixed two kinds of truth in one table. `planned_leave_day` was
simultaneously the allocator's output cache, the user's override store
(`is_pinned`, plus ad-hoc rows with no `wish_id`), and the resource ledger that
analytics and the age-4 maths read. The planner therefore had to ask "am I
allowed to touch this row?" on every sync, and got it wrong at the edges.

Every user assertion is now one `day_assertion` row — a concrete `day_type`
replaces a pinned day, a row with no `wish_id` replaces an ad-hoc day, and
`day_type='none'` replaces `planned_day_exclusion`. `planned_leave_day` becomes
purely derived with a single writer, and `PlanningService.pinned_keys()` is the
single answer to "is this day pinned", used by the allocator's loader, by
`sync_plan` and by the read router alike.

On top of that, every calendar band is now a real event: an ad-hoc band opens
the same full editor as a wish-backed one and saving it promotes it to a
`LeaveWish`, so it can be named, repeated yearly, assigned to either or both
parents, and handed to the planner. "Planering" is a `moveable` toggle plus a
from/to month bound plus a separate lock/unlock action on the days themselves,
replacing a three-rung ladder whose "planner decides" rung set a search window
equal to the drawn dates and so could never move anything.

Bugs found and fixed along the way:

- The plan erased its own history. Fixed windows clip to today, so an elapsed
  auto-placed day fell into `stale_keys` and was deleted on the next sync —
  and a background sync runs on every workspace load. Past rows are now frozen
  and counted as spent.
- Migration 010's downgrade silently destroyed every pinned day and exclusion
  (`is_pinned` returned as DEFAULT 0, the exclusion table came back empty,
  exit 0, no warning). It now reconstructs both from `day_assertion`, and 009
  itemises what it cannot recover before dropping the table.
- Deleting a period left its assertions behind, locking those dates forever
  with no UI path to clear them. Wish deletion now clears them by `wish_id`.
- `DayAssertionService` and `LeaveWishService` committed multi-statement writes
  without a transaction; a crash mid-write diverged the tables or half-deleted
  a series. Both now run in a unit of work.
- A sibling year's shortfall was never surfaced: the toast only inspected the
  edited occurrence's outcome, so a fully unfunded later year rendered as an
  empty band with no warning.
- A flexible window whose bound had entirely elapsed was dropped from the
  proposal with no outcome at all. It now reports as `unplaced`.
- Unlocking a period deleted its days instead of returning them to the planner.
- The e2e global setup posted to a route deleted in this change, which would
  have failed the whole suite before its first test.

Gates: backend 938 tests / 91% coverage, frontend 1351 / 97.4 | 92.2 | 94.37 |
97.4. Migrations 009 and 010 audited against a hand-built realistic database:
the upgrade reconciles exactly and a constraint violation fails safe, leaving
the schema at 008.

Not complete. Step 4's toggle, month picker and lock/unlock action are verified
by browser walk and unit tests, but the partial-lock readout was not exercised.
`ideas.md` §7 adds a full plan for the vacation-forfeiture defect (the planner
detects expiring days and then does nothing about them) — not implemented here.
Remaining smaller items are listed in the session's restructure notes.

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

frontend/src/i18n/en/calendar.ts

@@ -77,6 +77,13 @@ export const calendar = {
   'calendar.syncError': 'Failed to sync the plan',
   'calendar.syncingLabel': 'Syncing…',
   'calendar.toastChangedDays': '{name}: {count} {count|day|days} changed',
+  // A `removed` change with `evicted: true` — a row removed because a
+  // DIFFERENT wish's edit won a shared FP/vacation pool ahead of it, not
+  // because its own wish moved (see `PlanChange.evicted`'s doc comment in
+  // src/types/entities.ts). `sync_plan` always writes now, so this is
+  // reported here rather than as a separate rejection/preview.
+  'calendar.toastDisplacedDays':
+    '{name}: {count} {count|day|days} removed to make room for a higher-priority period',
   'calendar.toastGenericPeriod': 'The period',
   'calendar.toastShortfallNone':
     '{name} ({start}–{end}): none of the {weeksWished} {weeksWished|week|weeks} requested could be funded — {shortfallDays} {shortfallDays|day|days} short',
@@ -118,11 +125,36 @@ export const calendar = {
   'calendar.presetWeeksShort': '{count} wk',
 
   'calendar.periodAdHocTitle': 'Period',
-  'calendar.periodAdHocNotice': 'This period is not linked to a saved wish.',
+  'calendar.periodAdHocNotice': "This period isn't saved as a recurring wish yet. Give it a name and save.",
   'calendar.periodNameLabel': 'Name',
   'calendar.periodNameAria': "The period's name",
   'calendar.periodStartLabel': 'Start date',
   'calendar.periodEndLabel': 'End date',
+
+  // §Planering (restructure step 4) — replaces the three-way radio ladder
+  // with a toggle (where the planner may place the period) plus a separate
+  // lock/unlock action (see calendar.periodLock*). Same vocabulary as
+  // calendarDay.pinnedAria/plannedDayModal.autoOption.
+  'calendar.periodMoveableLegend': 'Planning',
+  'calendar.periodMoveableLabel': 'The planner may move the period',
+  'calendar.periodMoveableHint': 'The planner picks the best placement inside the chosen months.',
+  'calendar.periodFixedHint':
+    "The dates stay fixed. The planner still chooses each day's type unless it's locked.",
+  'calendar.periodBoundFromLabel': 'From month',
+  'calendar.periodBoundToLabel': 'To month',
+  'calendar.periodBoundLengthHint':
+    '{count} {count|day|days} — the planner picks where in the chosen period they land.',
+
+  // Lock/unlock is an action on the period's actually-saved days, not a form
+  // mode — locking can therefore be partial (see restructure step 4).
+  'calendar.periodLockLegend': 'Locking',
+  'calendar.periodLockStatus': '{locked} of {total} {total|day|days} locked',
+  'calendar.periodLockButton': 'Lock the days',
+  'calendar.periodUnlockButton': 'Unlock',
+  'calendar.periodLockUpdatingButton': 'Updating…',
+  'calendar.toastDaysLocked': '{count} {count|day|days} locked',
+  'calendar.toastDaysUnlocked': '{count} {count|day|days} unlocked',
+
   'calendar.periodRepeatLabel': 'Repeat',
   'calendar.periodRepeatNever': 'Never',
   'calendar.periodRepeatYearly': 'Yearly',
@@ -134,6 +166,10 @@ export const calendar = {
   // See backend/app/entities/leave_wish.py.
   'calendar.periodEditScopeLabel': 'Apply the change to',
   'calendar.periodEditScopeYear': 'Only this year',
+  // §Planering (step 4) — the previously silent trap: this is the default,
+  // so its limiting consequence must be as visible as "Every year"'s effect,
+  // or a saved edit looks like a no-op the moment you check another year.
+  'calendar.periodEditScopeYearHint': 'Other years in the series are not affected.',
   'calendar.periodEditScopeSeries': 'Every year',
   'calendar.periodEditScopeHint': 'Every year shifts the other years to match, keeping the weekdays.',
   'calendar.periodLastYearNeedsSeriesHint': 'Choose "Every year" to change the last year.',
@@ -152,13 +188,14 @@ export const calendar = {
   'calendar.periodDeleteYearButton': 'This period',
   'calendar.periodDeleteAllYearsButton': 'This period, every year',
   // "This day" now works on planner-placed days too: the removal is stored
-  // as a `PlannedDayExclusion` and survives every subsequent sync.
+  // as a `DayAssertion` with `dayType: 'none'` and survives every subsequent
+  // sync.
   'calendar.periodDeleteDayHint':
     'Only that day is removed. The rest of the period stays, and the planner will not add the day back.',
   'calendar.periodDeleteAllYearsDisabledHint': 'This period is not linked to a recurring plan.',
   'calendar.periodDeleteConfirmDay': 'Are you sure you want to remove this day?',
   // Names both the date and the parent: a day is removed for ONE parent, and
-  // the partner's day on the same date stays (see PlannedDayExclusionService).
+  // the partner's day on the same date stays (see Calendar.tsx's `excludeDay`).
   'calendar.periodDeleteConfirmDayNamed':
     'Remove {date} for {parent}? The day stays removed until you restore it.',
   'calendar.toastDayExcluded': '{date} removed for {parent}',