Add native SQLite record adapter (node:sqlite, FTS5, WAL) — #46 native adapter

[cuibonobo]

Summary

Builds the native adapter piece of #46: a new @haverstack/record-adapter-sqlite package on node:sqlite (Node ≥ 22.5, no native compilation), plus the shared-layer/core plumbing it needs. Scoped to just this package per discussion — adapter-local's swap to it, record-adapter-sqljs's browser-only cleanup, and doc updates are left for a follow-up pass.

record-adapter-sqlite:

• NativeSQLiteRecordAdapter implements StackRecordAdapter directly against node:sqlite's DatabaseSync. No export()/rewrite-the-whole-file step at all — native SQLite writes straight to the file under WAL journaling, so page-level writes, crash safety, and file locking come from the engine itself.
• FTS5 full-text search, with its own sanitizer (sanitizeFts5Query) reviewed against real FTS5 grammar rather than assumed from FTS4: NEAR is a function-call form here, not FTS4's infix operator, and FTS5 has real column-filter syntax that errors hard on unknown columns — both handled so they don't become new query-time failures.
• Opening a stack file created by record-adapter-sqljs transparently migrates its FTS4 index to FTS5 (detected via sqlite_master, rebuilt once) — cross-compatibility verified against a real sql.js-written file.
• FK enforcement (PRAGMA foreign_keys = ON, mapped to StackNotFoundError) and the same PID-lock-file storage-ownership guard as record-adapter-sqljs, now shared via sqlite-shared.
• deleteUnreferencedAttachmentRecords implemented as a real SQL transaction, matching record-adapter-sqljs's existing fix for the same check-then-act race.
• NativeTokenStore: a separate class/file implementing core's new StackTokenStore, storing bearer tokens outside the portable stack file by default (defaultTokenStorePath() derives a sibling path) — the fix requested in Split SQLite support: native record-adapter-sqlite for Node, browser-only record-adapter-sqljs, and a StackTokenStore interface in core #46's polish-backlog comment.

Two things I ran into and fixed along the way:

1. A real correctness bug: FTS5 external-content tables require the special INSERT INTO fts(fts, rowid, content) VALUES('delete', ...) command to unindex a row — a plain DELETE FROM records_fts leaves stale, still-searchable entries behind. Caught via direct testing against node:sqlite before it shipped; there's a regression test for it (full-text search reflects patchContent updates).
2. A Vitest/Vite bug where node:sqlite resolution drops the node: prefix and fails (vitest-dev/vitest#7177) — worked around by loading the module via process.getBuiltinModule() instead of a static import. That's the Node-sanctioned mechanism for exactly this class of bundler incompatibility, so it protects consumers who build with Vite-based tooling too, not just our own test suite.

sqlite-shared:

• New: FTS5_SCHEMA_SQL, sanitizeFts5Query, PRAGMA_JOURNAL_MODE_WAL, TOKENS_SCHEMA_SQL split out of RECORD_SCHEMA_SQL (tokens now live in their own schema fragment so each adapter can place them in whatever file it wants).
• The storage-ownership lock (acquireLock/releaseLock) moves here from record-adapter-sqljs — always pure Node fs/process logic, not sql.js-specific, so both engines share one implementation and one error message now.

core:

• New StackTokenStore interface + TokenInfo type: bearer-token issuance/lookup for server implementations, deliberately not part of the StackRecordAdapter contract (neither Stack nor StackClient touches it) and deliberately decoupled from record storage.

record-adapter-sqljs:

• Consumes the shared lock module instead of its own copy; TokenInfo now sourced from core. No behavior change — its 95 tests pass unmodified.

Test plan

• pnpm build / pnpm typecheck / pnpm lint — full monorepo, clean
• pnpm test — full monorepo, 582 tests passing, no regressions
• New record-adapter-sqlite tests (71): CRUD, queries incl. FTS5 search, associations, versions, permissions, restoreVersion, commitMigration, deleteUnreferencedAttachmentRecords, WAL mode enabled, FK enforcement, storage lock (reject/reclaim/force/release), FTS4→FTS5 migration (idempotent), NativeTokenStore (separate file, expiry, revoke, persistence across instances)
• New sqlite-shared tests: sanitizeFts5Query (NEAR term-preservation, column-filter stripping, parity with FTS4 sanitizer's known limitations), lock module (reject/reclaim/force/release) direct unit tests
• Manual verification scripts (not committed) confirmed: node:sqlite JSON1/FTS5/WAL/FK support, cross-file-compatibility between sql.js and node:sqlite, and the FTS5 delete-command bug before writing the fix

Refs #46.

https://claude.ai/code/session_01RRLiGUZC344E3pgNEGAe5W

---

Generated by Claude Code

[cuibonobo]

Follow-up commit: consolidated the duplication between record-adapter-sqljs and record-adapter-sqlite that was raised in review — the two adapters had near-identical method bodies (same SQL, same param order) for every CRUD/query/version/type/association/token operation, differing only in each engine's call convention (sql.js's array-bind-then-step vs. node:sqlite's spread-args run/get/all).

Added to @haverstack/sqlite-shared:

• SqlExecutor — a small interface (exec/run/get/all) normalizing the two conventions
• FtsStrategy — the one place FTS4/FTS5 genuinely differ (fts4Strategy/fts5Strategy)
• SharedSqlRecordLogic — every StackRecordAdapter method, written once
• SharedTokenLogic — every StackTokenStore method, written once
• insertConfigRecord/readStackConfig — the _config@1 record read/write

Both adapters now implement a thin per-engine SqlExecutor and delegate to the shared classes. Each package's index.ts is left with only what's genuinely engine-specific (init, pragmas, the FTS4→FTS5 migration, lifecycle).

record-adapter-sqljs's index.ts: 676 → 373 lines. record-adapter-sqlite's: 614 → 310 (+ a 23-line executor). No behavior change — every existing test in both packages (95 + 71 = 166) passes completely unmodified, which is the actual evidence this is behavior-preserving rather than just believed to be.

---

Generated by Claude Code