feat: Postgres memory backend (proper implementation) #74

Tracking issue for a production-ready Postgres/Supabase backend for the memory store. #40 was a good start but was closed pending the following:

Required before merging

1. Tests
The SQLite store has a full test suite. Postgres needs equivalent coverage. A Docker-based Postgres in CI (e.g. services: postgres in GitHub Actions) is sufficient — no live database required.

2. OnLifecycleEvent implementation
The Store interface requires OnLifecycleEvent(MemoryEventHandler). The SQLite implementation emits EventCompressed and EventEvicted from its decay worker. The Postgres implementation currently registers a no-op, meaning:

• Cache boundary hints are never fired for Postgres users
• Decay lifecycle callbacks are silently dropped

Options:

• Implement a polling-based decay worker for Postgres (e.g. periodic SELECT + UPDATE query)
• Or explicitly document it as unsupported and return an error if a handler is registered

3. Build tag or separate binary
pgx/v5 adds ~5MB to the binary even when Postgres is not used. Consider:

• //go:build postgres tag so the default binary stays lean
• Or a separate distill-postgres binary via GoReleaser

Out of scope

• Supabase-specific features (the DSN-based approach in feat: add Postgres/Supabase backend for memory store #40 already works with Supabase)
• Connection pooling (pgx handles this natively)

Reference

Original implementation: #40 (closed)