Cut over tooling to PostgreSQL and remove SQLite

[atomantic]

Complete the PostgreSQL migration after all runtime feature slices have landed: port operational commands, make PostgreSQL the only derived query backend, and remove the native SQLite dependency and dead compatibility code.

Depends on #149
Depends on #150
Depends on #151
Depends on #152
Depends on #153
Depends on #154

Scope:

• Port scripts/migrate.ts, prune.ts, purge.ts and still-supported data maintenance/sample/photo/generation commands to PostgreSQL or retire explicitly obsolete SQLite-only commands.
• Replace the SQLite migration runner with a PostgreSQL baseline/versioning workflow appropriate for a rebuildable derived store.
• Remove better-sqlite3/@types, sqlite.service.ts, sqlite-writer.ts, SQLite schema/migrations, stale isSqliteEnabled naming, and SQLite-only config/docs.
• Update development/deployment docs for DATABASE_URL, database creation, rebuild, backup/restore expectations, and JSON fallback behavior.
• Run full unit/integration/build validation and a clean JSON-to-PostgreSQL rebuild followed by representative API/UI smoke tests.

Acceptance criteria:

• Production/runtime code and supported scripts have no better-sqlite3 or sqliteService imports.
• npm install/build/test requires no native SQLite addon.
• A fresh environment can create the PostgreSQL database, initialize schema, rebuild from JSON, start the app, and use representative browse/search/mutation/audit flows.
• An unreachable PostgreSQL instance still leaves read-only JSON fallback behavior available where documented.
• The legacy data/sparsetree.db file is ignored rather than migrated or deleted automatically.

Files/areas: scripts/* SQLite consumers, server dependency manifests, legacy DB service/writer/schema/migrations, ecosystem/config/docs, test/build/release validation.

Part of #120

After this issue ships, check its box in #120. If it was the last open child, comment on #120 with a summary of the delivered children and close #120 as completed.