Make the inbox global instead of per-project

A card either sits in its owner's inbox (project_id AND status_id both NULL)
or belongs to exactly one project with a status in it (both set) -- enforced
by a CHECK constraint, never one without the other. The inbox is global to a
user now, not per-project: cards can move from a project into the inbox and
back into any status column of any project.

Backend
- migrations/009: rebuilds `cards` (SQLite can't relax NOT NULL / add a CHECK
  in place) with a nullable project_id, a new owner_id (cards need direct
  ownership once they can have no project), and the CHECK constraint. Cards
  that had no status (the old per-project inbox) move to the new global inbox.
  status_id's FK is now ON DELETE RESTRICT, not SET NULL -- nulling it alone
  would violate the invariant, and there's no status-delete endpoint anyway.
- CardRepository: "column" is now (owner_id, project_id, status_id); every
  method that dealt with a project's columns is generalised to also cover the
  inbox and cross-project moves (orderColumn, idsInColumn, repack, ...).
- CardController/routes: single-card and ordering routes move to global,
  since a card may have no project to nest them under --
  GET/PATCH/DELETE /api/cards/{id}, PUT /api/cards/order (body now takes
  project_id + status_id, both null for the inbox). New GET/POST
  /api/inbox/cards. PATCH no longer accepts status_id -- moving a card, in or
  out of a project, is exclusively PUT /api/cards/order now. A card created
  directly in a project (POST /api/projects/{id}/cards) lands in its first
  status, since a project card can't have no status.
- Tests: ProjectTest/CardStatusTest updated for the new routes; CardOrderTest
  rewritten with full inbox/cross-project coverage. 57 tests pass.

Frontend
- New stores/inbox.ts (the global inbox) and lib/cardOrder.ts (the shared
  PUT /api/cards/order call, used by both the sidebar and a project's board).
- AppSidebar: an Inbox section under the project list -- a vuedraggable list
  in the same "kanban" drag group as every project's kanban columns, so a
  card drags straight from the sidebar into whichever project is open, or
  back out. (The empty-inbox state needed a real bugfix: it wasn't rendering
  a <draggable> at all, so there was nowhere to drop a card back into an
  empty inbox.) A drop reloads the inbox and, if a project is open, its cards.
- ProjectView's kanban board drops its synthetic Inbox column -- just the
  real statuses now.
- DashboardView simplified to a plain grid of project tiles (name + card
  count); its per-project "New" section is gone, since a project card can no
  longer have no status.
- stores/cards.ts: patch/remove move to the global /api/cards/{id} routes.

Verified end-to-end against the rebuilt container (existing per-project-inbox
cards correctly migrated to the global inbox, 0 invariant violations) and the
dev server via headless Chrome: sidebar inbox -> project A "To do" -> back to
inbox -> project B "Done", full journey confirmed via the API at each step.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

README.md

@@ -18,8 +18,9 @@ Each user owns **projects**, and each project holds ordered **cards**.
 | 8 | Passwordless login — magic-link by default, password login behind a toggle | ✅ done |
 | 9 | Per-project card statuses ("To do" / "Doing" / "Done"); status chip, new cards start with none | ✅ done |
 | 10 | Project view — full-width, tabbed: alphabetical "All tasks" list + "Kanban" board, per-column drag ordering | ✅ done |
-| 11 | Persistent left sidebar (Dashboard link + project list/new-project form); dashboard = grid of projects with their "New" inbox cards | ✅ done |
+| 11 | Persistent left sidebar (Dashboard link + project list/new-project form); dashboard = grid of project tiles | ✅ done |
 | 12 | Passwordless-only auth — registration and password login removed; a magic link is the sole way in, and creates the account if needed | ✅ done |
+| 13 | Global inbox — cards can have no project; moved into the sidebar, drag in/out of any project's kanban columns | ✅ done |
 
 There is no password. Signing in is entering an email address and opening the
 magic link sent to it — the same step creates the account the first time. See
@@ -258,41 +259,44 @@ Creating a project also seeds it with three **statuses** — "To do", "Doing",
 
 ### Cards
 
-Scoped to a project; the parent project's ownership is checked first
-(`404` otherwise).
+A card either sits in its owner's **inbox** (`project_id` and `status_id` both
+`null`) or belongs to exactly one of their projects with a status in it (both
+set) — enforced by a database CHECK constraint, never one without the other.
+The inbox is global to the user, not per-project. Because a card may have no
+project, single-card and ordering routes are addressed globally, by the card's
+own id, rather than nested under a project:
 
 | Method | Path | Purpose |
 |--------|------|---------|
-| `GET` | `/api/projects/{id}/cards` | every card, grouped by column (inbox first) then `position` |
-| `POST` | `/api/projects/{id}/cards` | add a card |
-| `PUT` | `/api/projects/{id}/cards/order` | set the order/contents of one status column |
-| `GET` | `/api/projects/{id}/cards/{cardId}` | one card |
-| `PATCH` | `/api/projects/{id}/cards/{cardId}` | update `text`, `complete`, and/or `status_id` |
-| `DELETE` | `/api/projects/{id}/cards/{cardId}` | delete the card (`204`) |
+| `GET` | `/api/projects/{id}/cards` | a project's cards, grouped by status then `position` |
+| `POST` | `/api/projects/{id}/cards` | add a card directly to the project (its first status) |
+| `GET` | `/api/inbox/cards` | the caller's inbox |
+| `POST` | `/api/inbox/cards` | add a card to the inbox |
+| `GET` \| `PATCH` \| `DELETE` | `/api/cards/{cardId}` | one card, owner-scoped (`404` otherwise) |
+| `PUT` | `/api/cards/order` | set the order/contents of one column |
 
-Create body: `text` (required, 1–1000 chars), `complete` (optional bool,
-default `false`). `PATCH` needs at least one field.
+Create body (either creation route): `text` (required, 1–1000 chars),
+`complete` (optional bool, default `false`). `PATCH` accepts `text` and/or
+`complete` only — moving a card is done via the order route below, not PATCH.
 
 **Ordering.** `position` is a dense `0..n-1` rank *within a column* — the cards
-that share a `(project_id, status_id)`. The inbox (`status_id IS NULL`) is its
-own column. New cards go to the end of the inbox. There is no project-wide order.
+that share an `(owner, project, status)`. The inbox is its own column, per
+owner. `PUT /api/cards/order` sets one column's contents and order:
 
-A new card has **no** status (`status_id: null`) — it sits in the project
-"inbox" until the user gives it one. Two ways to move it:
+```json
+{ "project_id": 5, "status_id": 12, "card_ids": [3, 1, 2] }
+```
 
-- `PATCH …/cards/{cardId}` with `status_id` (a status id in this project, or
-  `null` for the inbox) — appends the card to the end of the destination column
-  and re-packs the one it left. `422` for an unknown or foreign status.
-- `PUT …/cards/order` with `{ "status_id": <id|null>, "card_ids": [3, 1, 2] }` —
-  makes those cards the exact contents of that column, in that order (positions
-  rewritten to `0..n-1`). Any card dragged in from another column is re-parented
-  and its old column re-packed, all in one transaction. `card_ids` must be
-  distinct cards of this project and must include every card already in the
-  target column (`422` otherwise). Returns `{ "cards": [ … ] }` for the whole
-  project. This is what the kanban board calls on every drop.
-
-A status row that is deleted clears itself from its cards rather than deleting
-them.
+`project_id`/`status_id` are both `null` for the inbox, or both set to a
+project owned by the caller and one of its statuses (`404`/`422` otherwise).
+`card_ids` must be distinct cards owned by the caller and must include every
+card already in the target column (`422` otherwise); it rewrites positions to
+`0..n-1`. Any card in the list that wasn't already in that column is
+re-parented into it — moving it from another project's status, or the inbox,
+or vice versa — and the column it left is re-packed, all in one transaction.
+Returns `{ "cards": [ … ] }` for the new column. This is what dragging a card
+in the kanban board (or the sidebar's inbox) calls on every drop; moving a
+card from one project to another is just two calls, via the inbox in between.
 
 Card representation:
 
@@ -304,23 +308,25 @@ Card representation:
     "text": "Design homepage",
     "complete": false,
     "position": 0,
-    "status_id": null,
-    "status": null,
+    "status_id": 2,
+    "status": { "id": 2, "name": "Doing" },
     "created_at": "2026-09-03T12:00:00Z",
     "updated_at": "2026-09-03T12:00:00Z"
   }
 }
 ```
 
-`status` is the embedded `{ id, name }` of the linked status, or `null` when the
-card has none. `GET …/cards` returns `{ "cards": [ … ] }`.
+`project_id` and `status_id` are `null` together for an inbox card. `status` is
+the embedded `{ id, name }` of the linked status, or `null`. `GET …/cards`
+returns `{ "cards": [ … ] }`.
 
 ### Statuses
 
 Every project has an ordered set of card statuses, created with the project:
 "To do", "Doing", "Done". They are project-specific — each project owns its own
-rows. There is no create/update/delete for the statuses themselves yet; a card
-is moved between them (or to the inbox) via `PATCH …/cards/{cardId}`.
+rows. There is no create/update/delete for the statuses themselves yet, and (as
+a project card must always have one) a referenced status can't be deleted at
+the database level either.
 
 | Method | Path | Purpose |
 |--------|------|---------|