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/e2e/tests/drag-create-delete.spec.ts

@@ -106,14 +106,17 @@ test('dragging a range and pinning an exact type plans every day exactly, and de
     })
     .toBe(1)
 
-  // Open it through its band — an ad-hoc band (no wishId) shows the plain
-  // date range and can only be deleted, not edited. `.first()` because the
-  // band may render as more than one DOM segment (see above); either one
-  // opens the same underlying period.
+  // Open it through its band — an ad-hoc band (no wishId) gets the full
+  // editor too (§"every calendar band is a real event"), seeded from its own
+  // pinned days; saving it would promote it to a real `LeaveWish`. This test
+  // only exercises delete, so it stops at the ad-hoc notice/seeded dates.
+  // `.first()` because the band may render as more than one DOM segment (see
+  // above); either one opens the same underlying period.
   await adhocBand.first().click()
   await expect(page.getByTestId('period-popover__content')).toBeVisible()
   await expect(page.getByTestId('period-adhoc-notice')).toBeVisible()
-  await expect(page.getByTestId('period-popover__content')).toContainText(`${firstDate} – ${lastDate}`)
+  await expect(page.getByTestId('period-start-input')).toHaveValue(firstDate)
+  await expect(page.getByTestId('period-end-input')).toHaveValue(lastDate)
 
   // todo.md #9 — the three delete scopes sit behind "Ta bort…". An ad-hoc
   // band has no recurring plan, so "every year" is disabled; "this day"/
@@ -183,7 +186,7 @@ test('a drag saved without opening Advanced creates a planner-funded wish, and t
 
   // Open the wish-linked band. Its own three-way remove: "this day" now
   // works on a planner-placed day too (the removal is recorded as a
-  // `PlannedDayExclusion` — see the next test); "this period" on a
+  // `DayAssertion` with `dayType: 'none'` — see the next test); "this period" on a
   // standalone (non-repeating) wish — one row, no series — removes the whole
   // thing, same as "every year".
   await wishBand.first().click()
@@ -206,8 +209,8 @@ test('removing a single day out of a planner-placed period keeps it removed acro
 }) => {
   // The user's requirement: "removing a single day should stay permanent.
   // Even if it's an auto added period day." The wish behind the band still
-  // asks for the whole window, so without a stored `PlannedDayExclusion` the
-  // next `POST /api/plan/sync` — which the calendar runs on every load —
+  // asks for the whole window, so without a stored `DayAssertion` (`dayType:
+  // 'none'`) the next `POST /api/plan/sync` — which the calendar runs on every load —
   // would simply put the day back.
   await registerAndReachOnboarding(page, uniqueEmail('remove-day'), 'Robin Testsson')
   await fillChildStep(page, 'Nova')