fix(memory-engine): compute update embeddings off the pooled connection

update_memory_unit re-embedded mid-transaction and update_mental_model
embedded inside the acquired connection, so an interactive edit held a
pooled connection across the embedder call.

update_mental_model now embeds before acquiring (its text depends only on
its arguments).

update_memory_unit is split into two phases:

- Phase 1 reads, resolves, and embeds off any connection, into typed
  _MemoryEditPlan / _MemoryRevertPlan.
- Phase 2 is a short write transaction that re-locks the row (FOR UPDATE),
  filters surviving entities, and applies the precomputed embedding.

The wider read-to-write window is covered by explicit guards:

- Abort (rollback and retry) if a concurrent edit changed an embedding- or
  resolution-input column between the phases.
- Reclaim orphan entities when an entity edit fails or is skipped, and
  re-lock the resolved set FOR UPDATE before linking to avoid an FK race
  with concurrent graph-maintenance pruning.

One bounded exception remains by design: when a concurrent prune (or a
same-unit entity-only edit) lands between the phases, Phase 2 and the
revert path re-embed once under the lock so the stored vector stays
consistent with unit_entities. There is no retry wrapper around
update_memory_unit, so this is preferred over surfacing a transient error,
and it is pinned by the curation tests.

Tests cover the two-phase edit, revert, concurrent-edit abort, orphan
reclaim, the prune-recovery re-embeds, observation invalidation, and
document transfer under the new acquisition model.

Author: zommiommy