feat(engine): pluggable memories storage backend

[nicoloboschi]

What & why

The memory_units table and the joins around it (memory_links, unit_entities) are as much a search index as a store — every recall arm (semantic, BM25, graph, temporal) is a query over them. Today that's hard-wired to Postgres SQL, scattered across the retain, recall, consolidation, curation and graph-maintenance paths.

This makes that slice a pluggable extension point, so a different engine can own memory storage and retrieval without touching how documents, chunks, banks, operations or the entity registry are stored. It's loaded like every other Hindsight extension:

HINDSIGHT_API_MEMORIES_EXTENSION=mypackage.memories:MyMemories
HINDSIGHT_API_MEMORIES_SOME_SETTING=value

With nothing configured, behaviour is identical to today — the default is now an explicit PostgresMemories implementation rather than the absence of one.

Shape of the change

• New interface MemoriesExtension (engine/memories/base.py) covering the write path, the recall arms, addressed reads, the graph view, observations and the maintenance passes. An implementation may be the sole store: it mints its own unit ids and carries entity postings / causal edges inline, so nothing memory- or link-shaped need reach Postgres.
• Default PostgresMemories is a thin delegator; its SQL moves unchanged into engine/memories/pg/{curation,graph,reads,writes}.py, grouped by what calls it. Because it's an explicit store, the default path stays the one the whole suite exercises.
• Every memories read and write goes through the store, and no call site branches on which one is installed — retain writes, recall + its source-fact/entity hydration, consolidation, curation views, tag/stat counts, mental-model staleness, the graph-visualization endpoint, and graph maintenance (an implementation whose links are inline has nothing to relink and no join table to sweep, so those passes no-op).
• Migration: observation_history drops its FK to memory_units, which assumed every observation is a row there — true only while Postgres is the store.
• Test: a self-contained store that touches no database at all is installed and driven through the interface, proving no call site reaches past the seam.

Compatibility & risk

• Default-on-Postgres behaviour is unchanged; the extraction is mechanical (queries relocated, not rewritten).
• No new required config. The extension env var is opt-in.
• Verified against the existing suite: the retain / recall / consolidation / curation / graph-filtering / graph-maintenance tests pass unchanged, plus the new seam test. (The only failures in the local run are pre-existing environment ones needing a live LLM key.)