sqlite: reject connection access from authorizer callbacks

[TrevorBurnham]

Fixes #63207

Per sqlite3_set_authorizer(), an authorizer callback must not modify the connection that invoked it, and sqlite3_prepare_v2() and sqlite3_step() both count. node:sqlite allowed the callback to call prepare(), exec(), the statement execution methods, and other connection-mutating APIs on the same DatabaseSync.

Authorizer reentrancy. Track authorizer depth on DatabaseSync with an RAII guard around the callback and throw ERR_INVALID_STATE from the affected entry points while it is on the stack. Depth is per-connection, so a different DatabaseSync stays usable.

Guarded: prepare, exec, serialize, setAuthorizer, createSession, applyChangeset, createTagStore, function, aggregate, enableLoadExtension, enableDefensive, loadExtension, the limits setter; stmt.run/get/all/iterate; iter.next/return; sqlTagStore.run/get/all/iterate; session.changeset/patchset. db.close() and db.deserialize() keep their existing callback-depth messages.

The guard covers every authorizer invocation, not just those from an explicit prepare(): SQLite may re-prepare during sqlite3_step() after a schema change, and serialize() and the session changeset methods prepare internally. Reentry through changeset() never terminated — it recursed until the process died, uncatchable from JavaScript.

Statement reentry. Covering the re-prepare path surfaced a memory-safety bug rather than a contract violation: a statement that is currently being stepped cannot be reentered. Finalizing it frees the virtual machine sqlite3_step() is running, and re-running it through run(), get(), all(), iterate(), iter.next(), iter.return(), or the equivalent tag store methods resets that virtual machine mid-execution. Both segfault, and neither is authorizer-specific — a user-defined function reaches them:

const { DatabaseSync } = require('node:sqlite');
const db = new DatabaseSync(':memory:');
db.exec('CREATE TABLE t (x INTEGER, txt TEXT)');
for (let i = 0; i < 200; i++) db.exec(`INSERT INTO t VALUES (${i}, '${'z'.repeat(500)}${i}')`);
let stmt;
db.function('boom', (x) => { try { stmt.run(); } catch {} return 1; });
stmt = db.prepare('SELECT boom(x), txt FROM t');
for (const row of stmt.iterate()) { void row.txt; }  // SIGSEGV before this patch

Swapping stmt.run() for stmt.close() or iter.return() crashes the same way, as does re-entering the same cached tagged literal on a tag store. A single reentrant call on a small result set often returns cleanly, so the crash needs a row payload large enough to force a page fault, or nesting.

Gating on "any callback is running" would forbid a UDF from preparing, running, and finalizing its own helper statement, which is safe. Instead, track the statements currently being stepped and reject reentry into only those, with statement is already being executed. Tracking is a stack, so a UDF may reenter an inner statement it stepped but not the outer one, and it spans the paired sqlite3_reset() calls, which can run JavaScript through an aggregate's xFinal. statement[Symbol.dispose]() returns early when already finalized, so disposal stays idempotent and can't demote a using scope's real exception to a SuppressedError.

Deliberately unguarded. Three APIs reachable from a callback are left available:

• backup() and Session.close(). sqlite3_backup_init() runs synchronously but sqlite3_backup_step() takes the source connection's mutex and blocks until the in-progress step finishes; a backup started from inside an authorizer completes and copies every row (also 120 stress iterations at rate: 1, no corruption). Deleting a session doesn't touch the VM under step.
• sqlTagStore.clear(). Dropping the cache releases strong references but never finalizes a statement synchronously — decrease_refcount() reaching zero calls MakeWeak(), and the statement being stepped is held by a stack BaseObjectPtr regardless — so it touches no SQLite state. Invalidating the cache after a schema change is a legitimate use of an authorizer, so this is now allowed rather than guarded.
• iterator.next() and iterator.return() on a drained iterator. The done_ check now precedes the guards, so a drained iterator keeps returning { done: true } instead of throwing.

[nodejs-github-bot]

Review requested:

• @nodejs/sqlite