sqlite: add virtual table support via createModule()

[TrevorBurnham]

Fixes #61539

This PR is a continuation of #61544 by @byteforge38, which became inactive.

It exposes SQLite's virtual table API through a new database.createModule(name, options) method, wrapping sqlite3_create_module_v2().

This PR enables read-only virtual tables backed by JavaScript data sources. A registered module can be used two ways:

• Eponymous table: query the module name directly (SELECT * FROM module_name).
• Named virtual table: CREATE VIRTUAL TABLE t USING module_name.

Hidden columns pass parameters via table-valued function syntax (SELECT * FROM module_name(param1, param2)).

options accepts columns, rows, directOnly, and useBigIntArguments.

Note: column affinity

A virtual table doesn't apply column affinity to the values xColumn returns, which makes declared types behave differently than they do on an ordinary table:

// real table: affinity converts the bound double
db.exec('CREATE TABLE t(v INTEGER)');
db.prepare('INSERT INTO t VALUES (?)').run(7);
db.prepare('SELECT typeof(v) FROM t').get();   // 'integer'

// virtual table: no affinity applied
db.createModule('gs', { columns: [{ name: 'v', type: 'INTEGER' }], *rows() { yield [7]; } });
db.prepare('SELECT typeof(v) FROM gs').get();  // 'real'

This follows from the conversion rules discussed in #63826: A number is bound as REAL, a bigint as INTEGER. Value-based coercion would make it impossible to yield 666.0 into a REAL column, and bigint already gives callers explicit control.

Coercing to the declared type would be a different mechanism, driven by explicit intent rather than by guessing from the value, and it would leave REAL columns alone. But SQLite core doesn't do this for virtual tables (generate_series returns integers because it calls sqlite3_result_int64, not via affinity), and it adds per-cell cost.

I've documented the current behavior rather than changing it, since coercing to the declared type is behavior SQLite core doesn't have for virtual tables.

[nodejs-github-bot]

Review requested:

• @nodejs/sqlite

[codecov]

Codecov Report

❌ Patch coverage is 81.97425% with 84 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.17%. Comparing base (68e0ce0) to head (f15a71d).
⚠️ Report is 89 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sqlite.cc	81.69%	42 Missing and 42 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65787      +/-   ##
==========================================
+ Coverage   90.13%   90.17%   +0.03%     
==========================================
  Files         769      771       +2     
  Lines      261645   265529    +3884     
  Branches    49671    50432     +761     
==========================================
+ Hits       235831   239432    +3601     
- Misses      16845    17000     +155     
- Partials     8969     9097     +128     

Files with missing lines	Coverage Δ
src/node_sqlite.h	87.27% <100.00%> (+0.86%)	⬆️
src/node_sqlite.cc	82.07% <81.69%> (-0.17%)	⬇️

... and 99 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trivikr]

An options getter can close the database after the initial state check, causing createModule() to segfault.

Please add this check after reading all options and column definitions

Suggested change

	// Options and column getters may have closed the database.
	THROW_AND_RETURN_ON_BAD_STATE(env, !db->IsOpen(), "database is not open");

Also add a regression test expecting ERR_INVALID_STATE for this case.

[trivikr]

When iterator cleanup throws, xClose() sets the SQLite error suppression flag even though SQLite ignores its return value. This leaves the flag set and silently swallows the next unrelated SQL error.

We should re-throw cleanup exceptions directly.

Suggested change

	// Re-throw so that an error already pending when SQLite unwound into
	// xClose still reaches the caller, and so that a throwing `finally` is not
	// silently discarded.
	if (try_catch.HasCaught() && !try_catch.HasTerminated()) {
	mod->PropagateJSError();
	// Re-throw cleanup exceptions directly. SQLite ignores xClose's return
	// value, so there is no corresponding SQLite error to suppress. Setting
	// ignore_next_sqlite_error_ here would suppress an unrelated later error.
	if (try_catch.HasCaught() && !try_catch.HasTerminated()) {

Please add a regression test for this.