Boards belong to a person: a guest's board lives in their browser and is kept by signing in #11

Give a board an owner, list mine on / when I am signed in, remember a guest's boards in their browser, and let signing in claim them.

Link sharing does not change: anyone with /b/<id> can still read and edit that board. Ownership decides only what / lists and who may claim an unowned board.

Done looks like

• [ ] board gains owner_id TEXT and owner_name TEXT, both nullable, added in the style src/db.ts already uses (idempotent at boot, existing rows stay unowned, the action undo log keeps working).
• [ ] A board created by a signed-in person is owned by them; a board created by a guest has no owner.
• [ ] / signed in: my boards, newest first, name and link, server-rendered. / as a guest: the boards this browser has visited, from localStorage, with one line saying they live in this browser only and a Sign in link that keeps them.
• [ ] Visiting /b/<id> records that id in the browser's list (a few lines in a content-named file under static/, no inline script — the CSP forbids it).
• [ ] POST /b/<id>/claim — same-origin, signed in — sets the owner when the board has none and does nothing otherwise; a board with an owner is never re-owned, and a guest's claim is refused. The board page offers it when a signed-in person opens an unowned board they hold.
• [ ] src/tty.ts keeps parity: its board picker shows boards owned by FORGE_APP_USER plus unowned ones, not everyone's.
• [ ] Tests: a board made under a signed identity has that owner; / lists only mine and never another person's board; claim succeeds once, is refused when owned and when anon; the link still edits a board I do not own.
• [ ] bun test passes.

Files

src/db.ts, src/routes.ts, src/pages/board.ts, static/boards.<hash>.js (new), src/tty.ts, src/server.test.ts, README.md.

Risks

Listing every board on / would leak boards across people — today's tty does exactly that, do not copy it to the web. A claim without the "unowned" check is board theft. Malformed localStorage JSON must not blank the page, and the list needs a cap so it cannot grow without bound.

Suggested brief: scout (the least that fully works, with tests).

Correction to this issue's last line: the briefs I named (ledger, torque) are not on this crew — I invented them in the run that opened this. The crew is atlas (planning), scout (builds), mason (maintains and refactors), sentinel (security review) and juniper (experience review). Read the suggestion here as scout to build, with sentinel reviewing the pull where the issue asks for a security review and juniper where the change is visible on the page. A person still assigns.