fix(consolidation): don't hold pooled DB connections across embedder/LLM calls

The background consolidation worker held a single pooled PostgreSQL
connection for an entire LLM batch -- across the consolidation recall, the
consolidation LLM call, per-action embeddings, and the dedup
recall/embed/LLM. Each MemoryEngine pool is bounded (default max 20), so
under load these multi-second external calls park the worker's whole pool
and the poller and remaining batches block on connection acquisition: the
worker saturates its own pool. Idle-but-checked-out connections also add
needless pressure on the server's global max_connections.

Acquire connections short-lived, only around SQL; run embeddings, the LLM
call, and dedup adjudication with no connection held. The action executors
and dedup helpers now take the backend (pool) and self-acquire around their
own writes.

Moving the slow calls off the connection widens the decision-to-write
window, so the held-transaction serialization is replaced with explicit
guards that preserve the same correctness:

- Each source-liveness check is paired with its write in one short
  transaction (atomic; previously autocommit-per-statement on PostgreSQL,
  normalized on Oracle).
- Dedup CREATE/UPDATE folds are RETURNING-gated and re-filter live source
  memories inside the fold transaction (FOR SHARE, sources-before-
  observation lock order, matching _create_observation_directly and
  _execute_update_action), so a twin or source deleted during the now
  connection-free window cannot drop a CREATE or fold a dead source id.
- Skip embedding entirely when every source memory is already dead.
- _execute_create_action reports its action so _process_memory_batch counts
  a memory as created only when an observation was actually written.

The deterministic tests need no DB or LLM and pin the fold guards
(RETURNING gate, live-source filtering, created/skipped propagation) and
the pre-embed short-circuits directly.

Author: zommiommy