[event memory recovery 1/2] Give EventMemory a store's shape, with a handle per partition - #1839

Purpose of the change

#1840 keeps event memory's two stores consistent through failed ingests and forgets. Its background work finishes what a failed request left in any partition, from one EventMemory the server starts at startup, whether or not a session is open. An EventMemory built around one session's two partitions, as it is before this PR, can't do that.

This PR gives EventMemory the shape of the stores it drives, so that #1840's diff holds the recovery protocol and the move to one EventMemory per deployment, and deletes a session's storage by key:

• EventMemory is built from the segment store, the vector store, and the models (segmenter, deriver, embedder, reranker, metrics factory). It has no data operations:
  • open_or_create_partition(key) opens or creates the key's partition in both stores, the vector store's first, and returns a handle.
  • delete_partition(key) deletes the key's partition from both stores.
  • The formatting helpers stay on it as static methods.
• EventMemoryPartition is the handle: encode_events, query, forget_events, and similarity_metric. EventMemory.open_or_create_partition builds it on one key's partition in each store, and it holds the two privately.
• Schema. A vector store answers store_schema, the schema it was built with. EventMemory checks once, when it is built, that its vector store's schema declares the fields it requires, and its handles take the declared fields and the similarity metric from that schema. VectorStorePartition no longer has a store_schema property; each store keeps its partitions' schema privately.
• Wiring. Until [event memory recovery 2] Keep event memory's two stores consistent through failed ingests and forgets #1840 moves the segmenter, deriver, and reranker to the deployment, each session chooses its own. So the service locator still builds an EventMemory whenever a session is opened, from the deployment's stores and embedder and the session's segmenter, deriver, and reranker, and opens the session's partition through it. LongTermMemory takes the session's handle, in place of both stores, both partitions, and the models.
• LongTermMemory takes the session's memory itself: a DeclarativeMemory, or an EventMemoryPartition with the episode storage that turns its results into episodes and the reranker that sets its score direction. Each request matches on the memory's type, and an EventMemoryPartition without episode storage is refused when the LongTermMemory is built. DeclarativeBackendParams, EventBackendParams, and their union go. The long-term service locator's long_term_memory_from_config builds the LongTermMemory in the arm that matches the configuration's backend, the declarative backend's DeclarativeMemory included. LongTermMemory has no lifecycle methods: drop_session_partition goes, and so does close, whose body did nothing. Its one search is query, as EpisodicMemory.query_memory above it and EventMemoryPartition.query below it are; it was search_scored.
• Deletion by key. LongTermMemory held the stores only to delete the session's partitions, so deleting a session built its whole memory, which opened, and could create, its partitions. Now the long-term service locator deletes a session's storage from its configuration, with a function that matches on the backend as its build function does: the event backend deletes the session's partitions by key through EventMemory.delete_partition, opening neither, and the declarative backend deletes the episodes its DeclarativeMemory of the session matches. EpisodicMemoryManager.delete_episodic_session closes a cached idle instance, then deletes the long-term storage the stored configuration names whenever that configuration builds long-term memory, and builds no EpisodicMemory. EpisodicMemory.delete_session_episodes goes; its short-term half only reset in-memory state. The evaluation scripts build the DeclarativeMemory they pass in, and delete a session through the same function.

Behavior that changes:

• Deleting a session no longer opens, or creates, its event-backend partitions first: the event-backend case of [Bug]: Deleting a session whose memory is not open creates its storage first, only to delete it #1728.
• A session saved with enabled: false has its long-term storage deleted too, where deletion returned before deleting anything.
• A vector store schema missing EventMemory's fields is refused when EventMemory is built rather than when a partition is opened.

Otherwise the stores are opened and deleted in the same order with the same arguments, and every data operation runs the same code. The names the two classes share (the reserved timestamp field and the text extraction) move to module level.

Stack

24 open PRs: three independent PRs, and the vector store tree of short parallel branches. Every open PR in the tree has feat/horizontal-scaling as its GitHub base, and the independent PRs have main. The branches are in a fork, and a pull request can target only this repository's branches, so the on column gives the order the PRs build on each other. A stacked PR's diff on GitHub includes the PRs under it until they merge.

Independent of the vector store tree, directly on main:

The vector store tree. Each PR builds on the one in its on column; PRs on the same parent are parallel branches and do not depend on each other. #1631 is closed, superseded by #1733–#1736, which hold its changes split in four, with review changes since. #1675 is closed, superseded by #1627. #1841 is closed: its request packing is dropped, and its cancellation contract is in #1840. #1828 and #1839 sit side by side on the branch; #1839 and #1840 are the event memory recovery stack, and #1684 heads the event memory stack, which its own PRs index, listed because it builds on #1840, its branch also carrying #1828's commits until one of the two merges; #1871 keeps its own Stack section. Until the PRs under it merge, their changes show in a stacked PR's diff.

This PR is its 12 commits, e125c9aeb, a6c1aaf88, 378c38cf6, 0750fb691, b827f3316, b97e81357, 6dc4ad6d5, 8319ec6e1, b3357dd24, 07122e98b, 1b1f8be62, 338428956, directly on feat/horizontal-scaling. #1840 is stacked on it.

Verification

At this PR's head 338428956, on feat/horizontal-scaling's 0fa52b38b:

• ruff check and ruff format --check are clean, ty check is clean as CI runs it (uv run --frozen --all-extras ty check --project packages/server), and uv lock --check passes.
• Server unit tests (packages/server/server_tests -m 'not integration'): 2356 passed, 8 skipped. Client unit tests (packages/client/client_tests): 259 passed.
• Integration tests through testcontainers: the event memory and segment store tests on PostgreSQL, 110 passed. At 8319ec6e1, the declarative LongTermMemory tests against Neo4j, 3 passed, and the vector store tests against Qdrant, Milvus, and the registry's PostgreSQL, 384 passed; the commits after it change neither those tests nor the code they run. The declarative tests' NebulaGraph half needs a running NebulaGraph and was not run.
• The test that deletes an event session with no open instance fails on feat/horizontal-scaling's 0fa52b38b, where deleting a session builds its memory and so opens its partitions.

🤖 Written by Claude Code (Claude Opus 5.5) on behalf of @edwinyyyu.