feat(db): add Postgres dialect against PGlite

[gordonkjlee]

Feature Change

Summary

Run the data-access layer against a real Postgres engine in tests, with a dialect adapter and a one-shot schema. Production still refuses postgres until a connection string is wired.

Stakeholder

N/A

Links

Ticket: N/A
Design doc: N/A

---

Description

This is not SQLite with a config flag. Tests open PGlite (Postgres compiled to WASM). The same insertFact / keywordSearch / insertEvent functions run against it.

Postgres schema is applied at the current version in one shot, recorded in schema_migrations — SQLite keeps its incremental pragma history. Word search is tsvector plus GIN, not FTS5. An identity rowid column preserves insert-order queries.

SQLite SQL is rewritten at the adapter: ? becomes $n, INSERT OR IGNORE becomes ON CONFLICT DO NOTHING, json(?) becomes $n::jsonb. Keyword search chooses a plainto_tsquery path when db.dialect is postgres.

The shipped server still refuses storage.provider: postgres and OPENMEMORY_STORAGE=postgres before opening a file. PGlite is a devDependency so the npm package does not grow a WASM engine.

---

Testing Evidence

• npm run build succeeds
• npm test — 803 passed, 6 skipped
• Rewrite unit tests for placeholders, OR IGNORE, OR REPLACE, datetime('now')
• PGlite: schema version, fact round-trip, keyword hit, named speaker, duplicate session-fact ignore, domain json, entity lookup, queued transactions and nested savepoints
• Existing CLI tests still refuse postgres in production

---

Complexity

• Simple (single tool or minor logic change)
• Moderate (multi-component or new capability)
• Complex (major feature, cross-cutting changes)

---

Checklist

• npm run build succeeds
• npm test passes
• Tool descriptions are clear and compelling (if MCP tools changed)
• No personal data or real memory content in the diff or this description (synthetic only)
• Code follows project standards
• Code is production-ready and can be reviewed