fix(deps): bump better-sqlite3 to v12 for Node 24 support (v1.54.1)

[siddharth-bhansali]

INT-4407

Problem

one sync is silently broken for anyone on Node 24 without a C++ toolchain — which is the default experience for a new user, since Node 24 is what you get installing Node today.

better-sqlite3@11 publishes prebuilt binaries only up to NODE_MODULE_VERSION 131 (Node 23):

v11.10.0 win32-x64:  node-v108  node-v115  node-v127  node-v131          ← no v137
v12.11.1 win32-x64:  node-v127  node-v137  node-v141  node-v147          ← Node 24 covered

Node 24 is 137, so prebuild-install falls back to node-gyp rebuild — compiling from source, which needs Visual Studio Build Tools on Windows. And because it's an optionalDependency, npm doesn't error, it silently skips it. The install succeeds, the CLI works, and one sync is dead with no warning.

Blast radius

Narrower than it sounds, but it hits the marquee feature. SQLite is only opened when a profile declares enrich (runner.ts:172, needsSqlite = !!profile.enrich) — 2 of the 9 built-in profiles:

• Broken: gmail, fathom — i.e. exactly the profiles the cross-platform identity-key work is built around. Plus sync delete, sync remove, and mem migrate (which is the tool for getting people off SQLite).
• Unaffected: attio ×2, google-calendar, hacker-news, notion, stripe ×2 — these never touch SQLite.

Verification

On this machine (Windows, Node 24.14.0):

• npm ci installs 12.11.1 clean — no compilation.
• pragma() and FTS5 both work; tsc --noEmit passes against the existing @types/better-sqlite3@^7.
• Full suite: 13 skipped → 0 skipped, 443/443 passing.

That last point matters beyond this PR. enrich-preserve.test.ts skips itself when the driver is missing, so it had been quietly not running here — which is exactly how the --no-memory regression in #180 reached CI instead of my machine. This restores local coverage of the enrich path.

Cost

v12 requires Node 20+, so one sync no longer works on Node 18. In practice it already didn't — v11 can't build there on a current toolchain either — but the README now states it explicitly rather than implying "Node 18+" covers everything. Every other command is unaffected on 18.

Worth knowing for review

CI cannot catch this class of bug. GitHub runners ship with compilers, so they build from source successfully and go green regardless of whether a prebuild exists. Adding Node 24 to the matrix would not have found this, and won't protect against the next occurrence — the protection is keeping the dependency current.

Lockfile. This needed a real regeneration, not a version-field edit. npm install --package-lock-only dropped node_modules/pg (an optional dep that can't install here), so I restored that entry by hand and validated the result with a clean npm ci. Documented the trap in CLAUDE.md so the next person doesn't ship a lockfile with pg missing.

Not bumped: @types/better-sqlite3 stays at ^7.6.13 (latest is 9.6.0). It typechecks clean against v12 and bumping it is unrelated risk — happy to split that out if you'd rather they moved together.

🤖 Generated with Claude Code

[linear]

INT-4407