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/pages/Settings.tsx

@@ -50,6 +50,7 @@ const PARTNER_ERROR_KEYS: Record<string, TranslationKey> = {
   'workspace.parents.invalidName': 'settings.partnerNameInvalid',
   'workspace.parents.remove.self': 'settings.removePartnerErrorSelf',
   'workspace.parents.remove.hasLogin': 'settings.removePartnerErrorHasLogin',
+  'workspace.parents.add.maxReached': 'settings.partnerActionErrorMaxReached',
 }
 
 // `hasDependentData`'s `data.blockers` is a subset of these four kinds —
@@ -280,7 +281,6 @@ export function Settings(): ReactNode {
   // `PlanSyncProvider.tsx`.
   const planSyncContext = usePlanSyncContextOptional()
   const latestProposalVersion = planSyncContext?.latestProposalVersion ?? 0
-  const pendingEvictionPreview = planSyncContext?.pendingEvictionPreview ?? null
   // The `latestProposalVersion` the recompute button's own triggered sync
   // should land past — `null` while no recompute is in flight, so a sync
   // started by something else entirely (e.g. a vacation-day autosave
@@ -306,16 +306,9 @@ export function Settings(): ReactNode {
       recomputeTimeoutRef.current = null
     }
     setIsRecomputing(false)
-    if (pendingEvictionPreview) {
-      // `wouldEvict === true` means the sync this button triggered wrote
-      // NOTHING (see `EvictionPreview`'s doc comment) — never report that
-      // as a success.
-      setSaveMessage({ type: 'error', text: t('settings.recomputeEvicted') })
-    } else {
-      setSaveMessage({ type: 'success', text: t('settings.recomputeSuccess') })
-    }
+    setSaveMessage({ type: 'success', text: t('settings.recomputeSuccess') })
     setTimeout(() => setSaveMessage(null), 3000)
-  }, [latestProposalVersion, pendingEvictionPreview, t])
+  }, [latestProposalVersion, t])
 
   // Settings isn't scoped to a single child the way Onboarding/Dashboard are
   // — the balance flow needs somewhere to attach a saved balance even before
@@ -599,9 +592,10 @@ export function Settings(): ReactNode {
   // Manual recompute: bumping `planVersion` is the whole implementation —
   // `PlanSyncProvider` (mounted app-wide) turns the bump into a
   // `POST /api/plan/sync` itself. Calling `api.syncPlan` directly here
-  // instead would bypass that provider's burst-coalescing and its
-  // `pendingEvictionPreview` handling. See the effect above for how the
-  // outcome (success vs. the sync writing nothing) gets reported.
+  // instead would bypass that provider's burst-coalescing. `sync_plan`
+  // always writes now (displacement is informational, never a refusal —
+  // see `PlanChange.evicted`), so the effect above only ever reports
+  // success once the triggered sync's proposal version lands.
   const handleRecompute = async () => {
     recomputeBaselineRef.current = latestProposalVersion
     setIsRecomputing(true)