fix(kernel-store): ask SQLite whether a transaction is open

[sirtimid]

The wasm driver tracked open transactions with its own _inTx flag. SQLite can roll a transaction back on its own after SQLITE_FULL, SQLITE_IOERR or SQLITE_NOMEM, and the flag stayed true. The next createSavepoint skipped its BEGIN, so its SAVEPOINT opened a transaction that RELEASE committed, and the driver's own COMMIT then threw cannot commit - no transaction is active. The flag never cleared, so later releases threw the same.

inTransaction is now a getter over sqlite3_get_autocommit. Init fails if the wasm build does not bind that function. A closed database reports no transaction open.

• beginIfNeeded clears the savepoint stack when it opens a transaction, in both drivers. The Node driver has had this bug since the savepoint stack was added (feat(kernel): Handle syscall failures #520); the wasm driver would have gained it with the live getter.
• The wasm kv and vatstore statements reset in finally, so one SQLITE_FULL no longer makes every later call to that operation throw SQLITE_MISUSE.

Testing

• wasm.transactions.test.ts and the new nodejs.transactions.test.ts run the drivers against real SQLite and fail a write with a real SQLITE_FULL (PRAGMA max_page_count). 'takes the next crank in a transaction of its own' and 'keeps taking kv/vatstore writes after one fails' fail on main. 'commits a write made after SQLite ends the transaction itself' fails without the wasm stack clear, and the Node test, whose write must survive closing and reopening the database, fails without the Node one.
• The mocked wasm.test.ts and nodejs.test.ts flip transaction state when BEGIN/COMMIT/ABORT run, as SQLite does, which fixed three assertions that could not fail. An it.each in wasm.test.ts pins the reset at each of the seven bound statements.
• Each fix was mutation-checked against the tests named here.

Resolves #1074

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes transaction and savepoint handling in the kernel persistence layer; bugs here could lose or fail to commit vat state, though the PR corrects known failure modes after SQLite auto-rollback.

Overview
Fixes kernel-store SQLite drivers when SQLite implicitly rolls back a transaction (e.g. SQLITE_FULL / I/O errors) while the driver still thought a transaction and savepoints were active.

The wasm driver stops caching transaction state in _inTx and exposes inTransaction from sqlite3_get_autocommit (init fails if that C API is missing). beginIfNeeded in both Node and wasm clears the savepoint stack when opening a new transaction so stale names cannot block commits or cause cannot commit - no transaction is active on later savepoint releases. Wasm KV/vatstore paths reset prepared statements in finally so one failed step does not poison later calls with SQLITE_MISUSE.

Tests add real-SQLite transaction suites (wasm.transactions.test.ts, nodejs.transactions.test.ts) and tighten mocks so BEGIN/COMMIT/ABORT flip transaction state like SQLite. CHANGELOG also records the separate better-sqlite3 ^13 bump (Node 22+).

^{Reviewed by Cursor Bugbot for commit 006ae98. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	73.65% ⬆️ +0.05%	10220 / 13875
🔵	Statements	73.41% ⬆️ +0.05%	10358 / 14109
🔵	Functions	73.55% ⬆️ +0.01%	2386 / 3244
🔵	Branches	68.47% ⬆️ +0.03%	4256 / 6215

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/kernel-store/src/sqlite/nodejs.ts	99.01% ⬆️ +0.01%	89.28% ⬇️ -7.14%	100% 🟰 ±0%	99.01% ⬆️ +0.01%	79
packages/kernel-store/src/sqlite/wasm.ts	100% ⬆️ +2.02%	95.23% ⬆️ +5.76%	100% 🟰 ±0%	100% ⬆️ +2.03%

Generated in workflow #5227 for commit 006ae98 by the Vitest Coverage Report Action