rivetkit 3.0.0-preview.2: worker segfaults when an actor with an FTS5 table closes its database #5921

Versions: rivetkit 3.0.0-preview.2 (@rivetkit/rivetkit-napi-linux-x64-gnu), engine
3.0.0-preview.2 (local binary from @rivetkit/engine-cli), Node 24 and 26, Linux x64.

Repro: an actor with db: db({ onMigrate }) that creates an FTS5 external-content
table with an insert trigger:

CREATE TABLE messages (sequence INTEGER PRIMARY KEY AUTOINCREMENT, text TEXT NOT NULL);
CREATE VIRTUAL TABLE search USING fts5(text, content='messages', content_rowid='sequence');
CREATE TRIGGER search_insert AFTER INSERT ON messages BEGIN
  INSERT INTO search(rowid, text) VALUES (new.sequence, new.text);
END;

Insert a few thousand rows, run any query, then c.sleep(). The worker logs
finalized statements left prepared on a closing sqlite database finalized_statements=8
and exits with SIGSEGV. Without the FTS5 table, sleep and wake work. With rivetkit
2.3.25 against the same 3.0 engine, the same actor sleeps and wakes fine.

Backtrace (crashing thread):

#0 measureAllocationSize
#1 sqlite3VdbeDelete
#2 sqlite3_finalize
#3 sqlite3Fts5IndexClose.part.0
#4 fts5DisconnectMethod
#5 sqlite3VtabUnlock
#6 sqlite3Close
#7 <sqlite_embedded::vfs::transport::NativeDatabase as Drop>::drop
#8 drop_in_place<sqlite_embedded::worker::OpenConnection>
#9 sqlite_embedded::worker::DatabaseSlot::perform

It looks like the close path finalizes every statement still prepared on the
connection, FTS5's own internal statements included, and then sqlite3_close
disconnects the FTS5 table, which finalizes them again.