fix(db): surface SQLite backend in status + actionable WASM-fallback banner (#148)

Closes the visibility gap behind issues #138 (WASM-on-macOS) and #139
(MCP "database is locked"). `better-sqlite3` is in optionalDependencies,
so when the native build fails npm install still succeeds and the
runtime silently falls back to node-sqlite3-wasm — 5-10x slower and
without WAL, so writers block readers (which is what makes the MCP
server appear to "lock the DB" in #139). The only existing signal was
a one-line `console.warn` to stderr that MCP transports typically
swallow.

This patch does NOT change install behavior — better-sqlite3 stays in
optionalDependencies so cross-platform installs keep working. It just
makes the substitution observable + recoverable.

## Visibility (4 surfaces)

- CLI `codegraph status`: new `Backend:` line under Index Statistics.
  `native` rendered green; `wasm` rendered yellow with an inline
  `npm rebuild better-sqlite3` nudge. Also exposed in `--json` as
  `backend: 'native' | 'wasm'`.
- MCP `codegraph_status`: new `**Backend:**` line. Native form reads
  `native (better-sqlite3)`; wasm form prepends a warning glyph and
  includes the full fix recipe.
- Stderr banner on fallback (`buildWasmFallbackBanner`): replaces the
  bare one-line `console.warn` with a multi-line bordered banner
  covering macOS + Linux fix steps and optionally appending the
  native load error.
- README troubleshooting: new "Indexing is slow / MCP database is
  locked / WASM fallback active" entry that walks users to the
  `Backend:` line and the fix.

## Per-instance backend tracking

`createDatabase` previously set a module-level `activeBackend` global.
MCP can open multiple project DBs in one process via the
`getCodeGraph()` cache, so the global would race / overwrite. Refactor:
`createDatabase` now returns `{db, backend}`, `DatabaseConnection`
carries `private backend` and exposes `getBackend()`, and
`CodeGraph.getBackend()` is the public surface. The CLI and MCP both
call `cg.getBackend()`.

## What this does NOT fix

The root cause of users landing on WASM is environment-specific (Mac
without Xcode CLT, Node version mismatch, etc.) and not fixable in
code without changing the optionalDependencies design. The README
entry tells users what to run; `Backend: native` after rebuild is the
confirmation signal.

## Tests

New `__tests__/sqlite-backend.test.ts` (6 tests) pins the banner
recipe content (so future edits can't strip the recovery commands),
the `WASM_FALLBACK_FIX_RECIPE` constant, and per-instance
`DatabaseConnection.getBackend()` / `CodeGraph.getBackend()` reporting.
Suite: 503 → 509, all passing.

Credit to @andreinknv whose analysis on #138 (and patches on his fork
at 6d0e7a2 + 69f7001) framed the visibility approach.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/index.ts

@@ -612,6 +612,16 @@ export class CodeGraph {
     return stats;
   }
 
+  /**
+   * Active SQLite backend for this project's connection. `wasm` means
+   * the native better-sqlite3 install failed and the WASM fallback is
+   * serving requests at 5-10x the latency. Surfaced via `codegraph
+   * status` and the `codegraph_status` MCP tool.
+   */
+  getBackend(): import('./db').SqliteBackend {
+    return this.db.getBackend();
+  }
+
   // ===========================================================================
   // Node Operations
   // ===========================================================================