Calendars as entities, uniform widget contract, multi-dashboard tasks

Architecture refinements before module work begins:

- Calendars become first-class entities (mirror of lists). Each
  calendar has its own visibility (private | household) and is
  independently shareable. Updated CLAUDE.md data model and task 10.

- Drop the singleton/parameterized split for dashboard widgets. Every
  widget declares a configSchema + defaultConfig + resolveConfigOptions
  and every placement is an independent instance — same widgetId can
  appear multiple times on one dashboard pointed at different things.
  Updated task 04 contract; tasks 11/12 widget sections aligned.

- Add tasks 25 (multiple dashboards per user) and 26 (customizable
  layout + widget configuration). Replaces the previously-considered
  three-task plan with a cleaner two-task split that the uniform
  contract enables. Phase 3 index updated; STATUS records the rationale.

- Task 20 reframed as a single-dashboard MVP that exercises the new
  contract end-to-end before the customization layer lands.

docs/tasks/25-multiple-dashboards.md

@@ -0,0 +1,73 @@
+# 25 — Multiple dashboards per user
+
+## Goal
+
+Each user can create any number of named dashboards, switch between them, and choose one as their default. No customization mechanic yet — that's task 26.
+
+## Why
+
+Decouples "the dashboard" from "user's home page". A user might have a *Daily*, *Garden*, and *Wedding planning* dashboard, each composing different widgets. This task introduces the entity; task 26 adds the editor.
+
+## Depends on
+
+- 20 (single-dashboard MVP — provides the layout shape we generalize from)
+
+## Scope
+
+### Schema
+
+```sql
+CREATE TABLE dashboards (
+  id uuid PRIMARY KEY,
+  user_id uuid REFERENCES users(id) ON DELETE CASCADE,
+  name text NOT NULL,
+  slug text NOT NULL,             -- url-safe, unique per user
+  is_default boolean NOT NULL DEFAULT false,
+  position int NOT NULL DEFAULT 0,
+  layout jsonb NOT NULL DEFAULT '{"version":1,"widgets":[]}',
+  created_at timestamptz NOT NULL DEFAULT now(),
+  updated_at timestamptz NOT NULL DEFAULT now()
+);
+
+CREATE UNIQUE INDEX dashboards_user_slug_uq ON dashboards (user_id, slug);
+CREATE UNIQUE INDEX dashboards_user_default_uq
+  ON dashboards (user_id) WHERE is_default;
+```
+
+Migration also copies each user's `default_dashboard_layout` (from task 20) into a single dashboard row named "Home" with `is_default = true`, then drops the `users.default_dashboard_layout` column.
+
+### Routes
+
+- `/` — redirect to the user's default dashboard (`/d/<default-slug>`).
+- `/d/[slug]` — render that dashboard. 404 if the slug doesn't belong to the current user. Layout rendering is unchanged from task 20 (still no edit mode).
+
+### Server actions
+
+- `createDashboard({ name })` — generates a slug from the name (collision-suffixed); empty layout; not default.
+- `renameDashboard(id, name)` — also re-derives slug if name changes (or keeps slug stable; pick stable, document it).
+- `deleteDashboard(id)` — disallowed if it's the user's only dashboard. If it was default, mark another as default before deleting.
+- `setDefaultDashboard(id)` — flip flags within a transaction.
+- `reorderDashboards(orderedIds)` — bulk update `position`.
+
+All gated on `dashboards.user_id = currentUserId`.
+
+### UI
+
+- **Switcher in the app header** — desktop: tabs strip with the user's dashboards in `position` order, an active indicator, a "+ new" tab at the end, and a kebab on the active tab for rename / set default / delete. Mobile: dropdown with the same actions.
+- **`/settings/dashboards`** — full management view: drag to reorder (use the same library task 26 will pull in, or a small `dnd-kit` setup — leave a note for task 26 to consolidate).
+- New-dashboard flow: prompts for a name, creates an empty dashboard, navigates to it. Empty state explains "this dashboard has no widgets yet — task 26 will add the picker." (Or, if 26 has landed, just "Add widget".)
+
+## Out of scope
+
+- Drag / resize / picker / configure (task 26).
+- Sharing dashboards with the household or via share-link (deferred; nullable `household_id` later).
+- Per-device or per-orientation layouts.
+
+## Acceptance criteria
+
+- [ ] Migration moves every existing user to a single `Home` dashboard with `is_default = true`. Idempotent.
+- [ ] User can create, rename, reorder, delete dashboards; cannot delete their last one; cannot have two defaults.
+- [ ] `/` redirects to the user's default dashboard's `/d/<slug>`.
+- [ ] Switcher renders in the header on both desktop and mobile, scoped to the current user only.
+- [ ] Server actions reject any operation against a dashboard the caller doesn't own.
+- [ ] No regression in task 20's layout rendering — existing widgets render identically inside the new route.