The record survives: an admin can export the decisions and restore them #10

Everything this app is for lives in one SQLite file under FORGE_APP_DATA; today there is no way to take a copy of it or put one back.

What done looks like

• src/backup.ts exports snapshot(db) — a consistent copy taken with SQLite's own VACUUM INTO into a temp path under FORGE_APP_DATA, so a write in flight cannot tear it — and exportJson(db), a plain object of every table's rows read from sqlite_master, so it keeps working as later issues add tables.
• GET /api/backup.db and GET /api/backup.json are admin-only at every door (forbidden for a user, signin_required for anon), with content-disposition: attachment; filename="quorum-<iso date>.db" and the security floor on both.
• A restore is deliberate and off the web: bun run src/backup.ts --restore <file> verifies the file is a SQLite database whose schema_version is no newer than this build's migration list, moves the current file aside with a timestamped name, puts the new one in place, and prints what it did. It refuses rather than guesses when the version is ahead, and it never runs from an HTTP request.
• bun run src/backup.ts --snapshot writes a snapshot beside the database and prints the path, so a person at the terminal can take one before anything risky.
• The /group page (or the admin section of whatever page exists) shows the database's size, the schema version, when the last snapshot was taken, and the two download links — for an admin only, and nothing at all for anyone else.
• Nothing is written outside FORGE_APP_DATA, at any point, including temp files.
• src/backup.test.ts covers: a snapshot of a database with rows opens and has the same rows; exportJson includes a table added by a later migration without being edited; a user and a guest are refused at both routes; restoring a file whose version is ahead is refused and leaves the original in place; restoring a valid file moves the old one aside and keeps its data reachable.
• README.md gains four lines: how to take a copy, how to put one back, and that a preview and production each have their own.

Files I expect to change: src/backup.ts (new), src/backup.test.ts (new), src/routes.ts, src/pages/group.ts (or the admin section that exists), src/actions.ts (the admin check as an action, so every door gets it), README.md.

Risks: a backup is the whole record in one file — the admin check belongs in the action, not the route, and the download must never be reachable by a guessable path without it. A restore replaces live data: refuse a newer schema, never delete the old file (move it), and keep the whole thing out of the HTTP surface. VACUUM INTO fails if the target exists — write to a fresh name and clean up after.

Fit: Hearth — a backup is a file you can restore from, and the panel says what is real. A person assigns; I do not.