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/utils/rejectionMessages.test.ts

@@ -35,6 +35,9 @@ describe('renderRejection', () => {
       'planApply.rejection.outsideEligibleWindow',
       'planApply.rejection.insufficientBalance',
       'planApply.rejection.insufficientVacationBalance',
+      'planApply.rejection.deleteKeyConflict',
+      'planning.rejection.vacationOnFreeDay',
+      'planning.rejection.parentalLeaveOnFreeDayDisabled',
     ]
     for (const messageKey of knownKeys) {
       const rendered = renderRejection(rejection({ messageKey }), t, [])
@@ -90,6 +93,39 @@ describe('renderRejection', () => {
     expect(rendered).not.toContain('pd-a')
   })
 
+  it('resolves the parent uuid in deleteKeyConflict to a name, not the raw uuid', () => {
+    const rendered = renderRejection(
+      rejection({
+        messageKey: 'planApply.rejection.deleteKeyConflict',
+        data: { date: '2026-06-15', child_id: 'child-1', parent_personal_data_uuid: 'pd-a' },
+      }),
+      t,
+      [member({ uuid: 'pd-a', name: 'Alex' })],
+    )
+    expect(rendered).toContain('Alex')
+    expect(rendered).not.toContain('pd-a')
+  })
+
+  it('interpolates the date into the free-day rejections', () => {
+    expect(
+      renderRejection(
+        rejection({ messageKey: 'planning.rejection.vacationOnFreeDay', data: { date: '2026-06-06' } }),
+        t,
+        [],
+      ),
+    ).toContain('2026-06-06')
+    expect(
+      renderRejection(
+        rejection({
+          messageKey: 'planning.rejection.parentalLeaveOnFreeDayDisabled',
+          data: { date: '2026-06-06' },
+        }),
+        t,
+        [],
+      ),
+    ).toContain('2026-06-06')
+  })
+
   it('leaves data with no parent uuid untouched', () => {
     const rendered = renderRejection(
       rejection({

frontend/src/utils/rejectionMessages.ts

@@ -37,6 +37,21 @@ const REJECTION_KEYS: Record<string, TranslationKey> = {
   'planApply.rejection.outsideEligibleWindow': 'planResults.rejectionOutsideEligibleWindow',
   'planApply.rejection.insufficientBalance': 'planResults.rejectionInsufficientBalance',
   'planApply.rejection.insufficientVacationBalance': 'planResults.rejectionInsufficientVacationBalance',
+  // Structural guard in `apply_proposed_days` — a key `sync_plan` wants to
+  // both delete (a stale row) and write (a fresh one) in the same batch.
+  // `sync_plan` computes `delete_keys` as exactly the stale keys NOT in its
+  // own fresh batch, so this should never actually fire today; kept here
+  // (rather than left unmapped) purely as defense-in-depth, since a rejected
+  // batch still reaches this same rendering path if it ever does.
+  'planApply.rejection.deleteKeyConflict': 'planResults.rejectionDeleteKeyConflict',
+  // The hand-pin "Advanced" path's authoritative guard
+  // (`app.services.day_guards.reject_illegal_free_day`, enforced by
+  // `DayAssertionService`), forwarded by `POST /api/day-assertions` —
+  // reached via `describePlannedDayError` in `Calendar.tsx`, not the
+  // plan-apply/sync toast, but the same lookup.
+  'planning.rejection.vacationOnFreeDay': 'planResults.rejectionVacationOnFreeDay',
+  'planning.rejection.parentalLeaveOnFreeDayDisabled':
+    'planResults.rejectionParentalLeaveOnFreeDayDisabled',
 }
 
 /** Renders one rejection, never leaking `data.parent_personal_data_uuid` as