feat(db): report the SQLite driver and its durability on the DB health check

[maxmad64bis]

Summary

• DbHealthCheckResult now reports which SQLite driver served the checked database, and whether
  that database's writes are durable: "driver": { "name": "sql.js", "degraded": true }.
• That was not answerable at runtime. driverFactory logs the chosen driver once at startup;
  omniroute doctor checks whether the better-sqlite3 native binary loads on disk, from its own
  process; and the payload of the endpoint whose job is DB health carried no driver field.
  Per fix(db): preserve runtime driver require in webpack standalone bundles #10552, a standalone bundle can rewrite the runtime require so the native driver fails to
  resolve inside the server while a fresh CLI resolves it fine — the server then runs on the
  sql.js WASM fallback while doctor reports green.
• degraded has exactly one meaning: writes are not durably backed by the database file. Two
  cases qualify — the sql.js WASM fallback, and an in-memory database, which getDbInstance()
  opens in cloud/build mode through the native cascade, so the driver name alone would read
  as healthy while nothing is persisted.
• Informative only: isHealthy stays defined by issues, so no existing check changes verdict.
• The field is read from the adapter the check ran against, so it cannot report a different
  database than the one inspected.

Also corrects the DATABASE_GUIDE health-check section, which documented a
{status, checks: {...}} payload this endpoint has never returned (orphaned_artifacts and
table_sizes have no source match in the repository). Its unterminated code fence left every
fabricated-docs claim below it unscanned; closing it surfaced SQLITE_FULL — a SQLite result
code quoted in prose, read by the gate as an env var — now allowlisted next to the other
prose-documented error codes.

Related Issues

• Related to fix(db): preserve runtime driver require in webpack standalone bundles #10552 (fixes the cause this makes observable)
• Related to fix(startup): better-sqlite3 not unpacked from app.asar → native module load fails → sql.js fallback OOM crash #7592, feat(dependencies): establish a first-class native SQLite baseline (better-sqlite3 lock + bun:sqlite parity) #8707, fix(startup): Windows Electron cold-restart fails — sql.js OOM on existing DB then Database closed loop #7132 (silent sql.js fallback and its consequences)

Validation

• Change type: DB / observability (+ docs)
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

$ node --import tsx/esm --test tests/unit/db-health-driver.test.ts
# tests 5   # pass 5   # fail 0

$ node --import tsx/esm --test tests/unit/db-health-check.test.ts     # pass 10  # fail 0
$ node --import tsx/esm --test tests/unit/db-core.test.ts             # pass 40  # fail 0
$ node --import tsx/esm --test tests/unit/db-core-extended.test.ts    # pass 27  # fail 0

$ npx vitest run --config vitest.mcp.config.ts \
    open-sse/mcp-server/__tests__/dbHealthTool.test.ts
Test Files  1 passed (1)      Tests  3 passed (3)

$ npm run typecheck:core 2>&1 | grep "error TS"
open-sse/services/compression/engines/omniglyphAdapter.ts(126,54): error TS2339: ...   # 1, pre-existing on base

$ npx eslint src/lib/db/healthCheck.ts tests/unit/db-health-driver.test.ts
0 errors

$ for g in check:docs-sync check:fabricated-docs check:docs-symbols check:doc-links; do
    npm run "$g" --silent >/dev/null 2>&1; echo "$g => rc=$?"; done
check:docs-sync => rc=0
check:fabricated-docs => rc=0
check:docs-symbols => rc=0
check:doc-links => rc=0

The single typecheck error is already tracked on the base and lives in a file this PR does not
touch.

⚠️ base-red inherited: #9985

Tests Added Or Updated

• tests/unit/db-health-driver.test.ts (new, 5 tests): describeDbDriver flags sql.js as
  degraded, flags every driver as degraded for :memory:, and leaves the three native drivers
  undegraded on a file-backed database; runDbHealthCheck against a real database reports a
  driver equal to the adapter's own db.driver; and an in-memory database opened through the
  same tryOpenSync cascade the cloud/build path uses really reports name === ":memory:".

Coverage Notes

• Touched src/: describeDbDriver() (pure, all branches covered) and the single construction
  site of DbHealthCheckResult, covered by the real-database test above.
• No coverage moved down; the production change is additive.

Reviewer Notes

• No migration, no feature flag, no change to request handling.
• DbHealthCheckResult gains one required field. It has a single producer, and both consumers
  (/api/db/health, omniroute_db_health_check) serialize the whole result, so no further
  wiring is needed.
• driver is nested rather than two flat fields so the two facts stay grouped and a later
  persistence refinement needs no third root field — happy to flatten it for consistency with
  the surrounding style.
• Deliberately not folded into isHealthy: a database on sql.js still works, and turning working
  installations red would change an existing check's verdict inside an observability change.
• getDriverInfo() / setDriverInfo() in src/lib/db/core.ts answer a different question — how
  better-sqlite3 was resolved, not which driver is serving — and have no production caller.
  Left untouched; removing or reviving them belongs in its own PR.
• The check-fabricated-docs allowlist entry is a pre-existing false positive that the broken
  fence had been hiding, not a new violation: the unmodified file passes the gate, and the same
  file with only the missing fence closed fails on SQLITE_FULL.
• Two unrelated formatting hunks in healthCheck.ts come from the repository's own
  lint-staged Prettier pass — the committed file predates the current formatting on those
  lines.

[diegosouzapw]

Reviewed #10652. Verified all 3 red checks on this run (Fast Quality Gates, Unit Tests fast-path 2/4 and 3/4) are pre-existing base-red on release/v3.8.50 — reproduced the same compression/omniglyph failures on a clean base checkout with none of this PR's changes applied. Ran the PR's own tests (db-health-driver.test.ts 5/5, db-health-check.test.ts 10/10) plus eslint on the touched files — all clean. Confirmed the driver type is derived from the adapter's closed union (no drift risk) and that both consumers (/api/db/health, omniroute_db_health_check MCP tool) already serialize the whole result object, so no additional wiring was needed. Looks merge-ready.