Retire the SQLite backend — Postgres is the only engine

The dual backend (SQLite via db.js + Postgres via schema.pg.sql) was a
maintenance foot-gun: a schema change could land on the SQLite path only and
silently 500 every read on prod (it just did, with #18/#13). Production has run
on Postgres for weeks, so SQLite is retired: ONE schema source of truth
(db/schema.pg.sql), no drift possible.

- dbx.js: default DB_BACKEND=pg; an unknown backend now fails loudly at require
  time instead of silently selecting a stale engine.
- Deleted server/db.js, server/db/sqlite.js, server/db/migrate-sqlite-to-pg.js,
  server/scripts/migrate-bizgaze-only.js (all SQLite-only, none in the runtime
  path — the running server loads db/pg.js).
- Tests (e2e, db-smoke) target Postgres now and fail-fast (skip) unless
  DATABASE_URL points at a disposable test DB — never SQLite, never prod.
- Removed the dead DB_PATH env + fixed misleading SQLite comments in the
  Dockerfile / docker-compose (kept the /data volume: it holds
  uploads/recordings/transcripts/downloads, not just the old data.db).
- CLAUDE.md: stack + repo-layout + run-locally updated for Postgres-only.

Runtime is unaffected (prod already sets DB_BACKEND=pg and pg is a prod dep);
this only removes the unused SQLite path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

server/dbx.js

@@ -1,6 +1,10 @@
-// Async DB adapter facade. The backend is chosen by DB_BACKEND (default 'sqlite'); 'pg' is added at
-// cutover. Every backend implements the same async interface — prepare(sql).{get,all,run}, exec(sql),
-// tx(fn), init() — so repos and app code are engine-agnostic. Swapping engines is one backend file, no
-// repo changes. (This is the same "never hardwire the engine" principle we'll apply to the pub/sub layer.)
-const name = process.env.DB_BACKEND || 'sqlite';
+// Async DB adapter facade. Production runs PostgreSQL. SQLite was RETIRED on 2026-08-12 so there is exactly
+// ONE schema source of truth (db/schema.pg.sql) — no more dual-maintenance drift between a SQLite migration
+// list and the PG schema (that gap once made a column land on SQLite only and 500'd every read on prod).
+//
+// DB_BACKEND is kept for future swappable backends but defaults to 'pg', and only 'pg' ships today. An
+// unknown value fails LOUDLY here at require time (module-not-found) rather than silently selecting a stale
+// or non-existent engine. Every backend implements the same async interface: prepare(sql).{get,all,run},
+// exec(sql), tx(fn), init().
+const name = process.env.DB_BACKEND || 'pg';
 module.exports = require('./db/' + name);