Core sync: native SQLite adapter, StackTokenStore composition, tokens out of the portable stack file (core #46, #45)

[cuibonobo]

Server side of haverstack/core#46 (SQLite split) and the remaining haverstack/core#45 items. This server is the primary beneficiary of the native adapter — it currently pays sql.js's whole-file-rewrite on every write.

Work items

Adapter swap (core #46)

• Bump @haverstack/adapter-local when it swaps to record-adapter-sqlite — API-invisible in theory, but verify: Node engine floor rises to ≥22.5 (we already require ≥22.9 in package.json, fine), FTS4→FTS5 rebuild happens transparently on first open of an existing stack.db, WAL means DB_PATH gains sidecar files (-wal/-shm) — update the Docker volume/deployment docs which currently say the directory holds "the SQLite database and attachments"
• Double-open protection (core POST /attachments bypasses the permission layer: any token holder gets ungated blob storage #45 item 4): when the lock lands, a second server process against the same DB_PATH should fail loudly at startup — add a test and a clear operator-facing error message

Token storage (core #46 §4)

• Type against StackTokenStore instead of LocalAdapter's token methods (src/middleware/auth.ts, src/routes/tokens.ts, TokenInfo import moves to core); compose { adapter, tokens } explicitly in src/stack.ts rather than sniffing token methods off the adapter
• Move tokens out of the portable stack file. Core Attachment upload buffers the entire body in memory before the size check #46 records the hygiene problem: auth material currently travels with data exports, and restoring a backup resurrects revoked tokens. The interface decoupling makes it possible; this server should actually do it — a separate token DB beside (not inside) stack.db, excluded from "your data, take it with you" flows. Needs a small migration for existing deployments (copy token rows out on first boot)
• PRAGMA foreign_keys / transaction items from the core Attachment upload buffers the entire body in memory before the size check #46 comment thread arrive via the adapter; server tests around deleteAttachment race behavior may need updating

Deployment doc gains a note: with WAL + real locking, multi-process storage safety improves, but the single-writer topology stands for the trust-boundary reason (permissions only exist behind this server) — core #45's framing, worth restating where operators will read it.

Refs haverstack/core#46, haverstack/core#45, #42 (DID auth builds on the same token store).