fix(db): bundle and verify the sql.js fallback

[nguyenha935]

What changed

• keep SQLite driver imports as literal require() calls so the standalone bundler emits real externals instead of missing-module stubs
• ship the complete sql.js runtime, including its WASM asset, in standalone packages
• make the sql.js adapter resolve its runtime from the installed package tree
• extend check-pack-boot with a forced-sql.js round trip and a two-boot persistence check using the same DATA_DIR
• add regression coverage for driver order, writable reopen behavior, standalone assembly, externalization, and persistence evaluation

Root cause

The fallback path worked from source but was not a reliable packaged-runtime contract. Passing require through a loader callback prevented the bundler from seeing literal SQLite module specifiers, while the standalone assembly did not guarantee that the complete sql.js runtime was present. This could leave an installed package unable to recover when a native SQLite binding was unavailable.

Impact

Packaged OmniRoute installations can safely preserve the existing driver cascade:

1. better-sqlite3
2. node:sqlite
3. bun:sqlite
4. sql.js

The pack-boot gate now verifies that the fallback can write settings, shut down cleanly, start again against the same database directory, and read the persisted value back.

Validation

• focused SQLite suite after rebasing onto the current release/v3.8.50: 34 passed, 0 failed, 1 skipped
• the single skip is the native better-sqlite3 preference probe in a scratch image without that native binding; cascade and fallback behavior remain covered
• production artifact verification on a deployed patched build:
  • graceful shutdown completed a WAL checkpoint and closed SQLite
  • the replacement process reopened the same /opt/omniroute/data/storage.sqlite
  • runtime state and existing proxy logs were loaded after restart
  • PRAGMA quick_check returned ok; journal mode is wal
  • sql.js/dist/sql-wasm.wasm is present in the installed runtime

No Home topology or Model Identity changes are included in this PR.

[diegosouzapw]

Merged via local merge-train on 192.168.0.113 (32 cores) @ train tip 7eb0840f219a403081d79244e61e7747cfec92a4 — log /srv/omniroute-train/.claude/worktrees/train-20260804-200844-suite.log.

Green: typecheck:core, check-complexity, check-cognitive-complexity, check-changelog-integrity.

This was the first train of the day to run against a genuinely clean base — #9447 and #9392 had just taken the release back to green after 15 unit failures inherited from #9275 — so every red here was re-run in isolation on the exact train tip rather than assumed. All of them passed:

Failure	Suite	Isolated on the train tip
consoleInterceptor-writes — log-unavailable notice	unit	6/6 pass (also failing on the bare tip)
modelsDevSync-extended — duplicate timers	unit	13/13 pass (also 13/13 on the bare tip)
audit.test.ts ×3 (shutdown checkpoint, node:sqlite fallback)	vitest	pass — the documented WAL/timeout-under-load flake class
Sidebar.search.test.tsx ×2	vitest	pass — timed out at 20s/10s under the full concurrent run

No failure was attributable to any boarded PR.

For reference, check-file-size remains a pre-existing base-red on the bare tip (src/sse/handlers/chat.ts 1846>1845, open-sse/executors/base.ts 1623>1578) — baseline drift for the release captain.