Complete NextSteps roadmap: planning engine UI, calendar cluster, flexible wishes

Works through every numbered item in NextSteps260913.md section 3, plus the
three known verification issues in section 4.1.

Surface what the backend already computed:
- 3.1 render surplus_advice in PlanResults, mirroring the shortfall remedies
- 3.2 surface VacationBalance.is_assumed so assumed statutory years are visible
- 3.3 age-4 expiry given the proposed plan, via a new Age4Projection reusing
  the existing _age4_projections arithmetic (Dashboard stat verified, not rebuilt)

Calendar cluster (one pass over the holiday data):
- new GET /api/calendar/days exposing roda dagar, klamdagar and day overrides,
  paginated four years at a time
- 3.4 shade roda dagar/klamdagar, with R/K badges so colour is not the only signal
- 3.6 click-to-override behind an explicit mode toggle, leaving drag multi-select intact
- 3.7 click month/year to advance
- 3.8 per-year red-days list in Settings, statutory days plus overrides

i18n:
- 3.5 five backend-generated Swedish surfaces converted to message_key + data,
  following the tips_service pattern; old string fields replaced, not kept

Flexible wishes (3.9):
- PLANNING_ENGINE_SPEC section 10: window_mode, candidate search, cost function,
  deterministic tie-break, two-pass ordering, test matrix rows 15-24
- backend: entity, migration 006, _FULL_SCHEMA sync, repository, allocator
- frontend: season-preset toggle in WishEditor, unplaced outcome rendering

Fixes (4.1):
- pin typecheck to the local tsc rather than npx resolving a newer TypeScript
- ignore generated coverage/ and dist/ in the ESLint flat config
- fix the flaky usePlanApply test properly, with waitFor rather than a retry

Tests: backend 361 -> 404, frontend 540 -> 704. Coverage 89.47% -> 96.52% lines.

Not yet verified in a browser.

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

backend/migrations/versions/004_add_day_override.py

@@ -0,0 +1,54 @@
+"""Add day_override table.
+
+Lets a workspace correct the calendar cache (`app/data/swedish_calendar.json`)
+in either direction on a per-date basis: `is_working_day=false` means the
+workspace is off that day even though the calendar calls it a working day
+(e.g. a klämdag their employer gives off); `is_working_day=true` means the
+workspace must work despite the calendar (e.g. julafton is a normal workday
+there). See PLANNING_ENGINE task notes / app.services.allocation_service.
+
+Revision ID: 004
+Revises: 003
+Create Date: 2026-09-13
+"""
+
+from __future__ import annotations
+
+from alembic import op
+
+revision: str = "004"
+down_revision: str | None = "003"
+branch_labels: str | None = None
+depends_on: str | None = None
+
+_UPGRADE_SQL = """
+CREATE TABLE IF NOT EXISTS day_override (
+    id TEXT PRIMARY KEY,
+    workspace_id TEXT NOT NULL,
+    date DATE NOT NULL,
+    is_working_day INTEGER NOT NULL,
+    note TEXT,
+    created_at TIMESTAMP NOT NULL,
+    updated_at TIMESTAMP NOT NULL,
+    UNIQUE(workspace_id, date),
+    FOREIGN KEY (workspace_id) REFERENCES workspace(id) ON DELETE CASCADE
+);
+"""
+
+_DOWNGRADE_SQL = """
+DROP TABLE IF EXISTS day_override;
+"""
+
+
+def upgrade() -> None:
+    from sqlalchemy import text
+
+    for stmt in [s.strip() for s in _UPGRADE_SQL.split(";") if s.strip()]:
+        op.execute(text(stmt))
+
+
+def downgrade() -> None:
+    from sqlalchemy import text
+
+    for stmt in [s.strip() for s in _DOWNGRADE_SQL.split(";") if s.strip()]:
+        op.execute(text(stmt))