[event memory recovery 2] Keep event memory's two stores consistent through failed ingests and forgets - #1840

…tion

A vector store's schema is fixed when the store is built, so EventMemory
takes it as a parameter, the same schema the composition root built the
vector store with, rather than reading it from each partition it opens.

- EventMemoryParams gains `store_schema`. EventMemory checks once, at
  construction, that the schema declares the fields EventMemory requires,
  and hands each partition handle the declared fields and the similarity
  metric. A handle's `similarity_metric` and its score direction come
  from them.
- The service locator builds the vector store and EventMemory from one
  schema, `event_backend_store_schema`.
- `VectorStorePartition` no longer has a `store_schema` property; each
  store's partitions keep the schema privately.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

LongTermMemory has had a single search since its unscored `search` went,
so `search_scored` no longer tells it apart from anything. It is `query`,
as the calls above and below it are: EpisodicMemory.query_memory and
EventMemoryPartition.query. Its two backend branches are
`_query_declarative` and `_query_event`. DeclarativeMemory keeps
`search_scored`, which it tells apart from its unscored `search`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Once the service locator built each backend's memory, the two backend
params differed only in that memory: a DeclarativeMemory, or an
EventMemoryPartition with the episode storage that turns its results into
episodes and the reranker that sets its score direction. LongTermMemory
now takes the memory itself, with those two as keywords, and each request
matches on the memory's type. An EventMemoryPartition without episode
storage is refused when the LongTermMemory is built.

DeclarativeBackendParams, EventBackendParams, their union, the backend
literal, and the session id, which nothing read, go. The service locator's
`long_term_memory_from_config` builds the LongTermMemory in each match arm,
and the episodic service locator takes it from there. The evaluation
helper passes its DeclarativeMemory directly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The episodic service locator's `delete_episodic_memory_storage` only
checked whether the stored configuration builds long-term memory and
passed it on. EpisodicMemoryManager.delete_episodic_session now makes that
check and calls `delete_long_term_memory_storage` itself, so deleting a
session goes from the manager straight to the long-term layer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Event memory bounds when its vector writes are sent by cancelling an
upsert at a deadline, which needs a written guarantee of what cancelling
does. VectorStorePartition.upsert now states that cancelling the call
stops it from sending further requests to the backend, and that a
request already sent may still be applied, so a cancelled upsert may
have written some of the records. RegistryBackedVectorStorePartition's
`_upsert` hook states the same obligation for its implementations.

Every implementation honors it:

- RegistryBackedVectorStorePartition awaits the registration check,
  `_upsert`, and the check again in sequence, so a cancellation stops at
  the await it lands on.
- Qdrant and Milvus await each request, and send the halves of a batch
  the server refuses as too large one after another, so a cancellation
  raised in a request ends the call. Neither client catches
  CancelledError: qdrant-client's REST path catches Exception only, and
  pymilvus's retry decorators catch grpc.RpcError, MilvusException, and
  Exception, so a cancelled RPC surfaces as CancelledError and is not
  retried.
- sqlite-vec writes in one transaction. A statement already queued to
  aiosqlite's thread finishes there; SQLAlchemy treats the cancellation
  as a disconnect and invalidates the connection, so the transaction
  never commits and nothing more is executed on it.
- The engine-backed SQLite store commits its records and pending
  operations, then applies them to the search engine, then marks them
  applied. A cancellation in the engine step leaves the operations
  pending, and startup replays them.
- The in-memory test partition has no await in its upsert.

Tests cancel an upsert mid-call and check that nothing more goes out:
for Qdrant and Milvus with a fake client that refuses the batch as too
large and holds its first half (the second half is never sent, and the
registration is not checked after it), and against the server (the
request in flight; for Milvus counted at the gRPC stub, so a pymilvus
retry would show); for both SQLite stores, cancelling at the upsert's
first statement, and for the engine-backed one also while its search
engine applies the records, no further statement executes.

Verification: ruff, ruff format, and ty clean; the vector store unit
tests, 401 passed, 5 skipped. The fake-client tests fail when the
halving swallows the cancellation and sends the second half. The
integration tests need Docker and were not run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…forgets

The segment store and the vector store share no transaction, so an ingest
that stopped after storing its events left them unsearchable, and a forget
racing an ingest or a late vector write could leave vectors of forgotten
events behind.

The segment store now holds the events themselves, and two queues of work
the vector store still owes:

- Pending derivatives: an ingest stores its events, segments, derivative
  links, and one pending record per event in one transaction, upserts the
  vectors within a write budget, and deletes the record. A record left
  behind is claimed by any process once the budget has passed, and
  written again within a budget of its own.
- Tombstones: a forget locks its events, deletes their pending records,
  records the derivatives it unlinked in one tombstone, and deletes the
  events in one transaction. The vectors are deleted at once and again
  after the tombstone retention, which outlasts any write sent within
  its budget.

Claims hold a lease, back off doubling on failure, and stop after
repeated failures, which is logged. A search drops a hit with no link
and deletes its vector once, best effort. Partitions are deleted from
the segment store first. Each purge call stays within its bound across
segments, events, and the derivatives tombstones name.

design/event_memory_ingest_and_deletion.md gives the protocol and why
it is safe.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

EventMemory's background work claims pending derivatives and tombstones
from the whole segment store database, and its records name no vector
store or embedder: it writes and deletes with its own. That is right only
if one EventMemory serves every partition in the database, and only if it
runs whether or not a session is opened.

The resource manager now builds the deployment's EventMemory from the
episodic memory's long-term memory configuration, starts its background
work, and shuts it down on close. The server builds it at startup when
that configuration names a segment store. A session opens its partition
on it, and the deployment's segmenter, deriver, and reranker serve every
session.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…deployment

The deployment's one EventMemory serves every event session with its own
segmenter, deriver, and reranker, so the copies a session saved no longer
apply. The session's event configuration no longer has those fields, and
rows saved earlier load with them ignored; creating a project checks a
reranker only on the declarative backend.

A project's `reranker` applies to the declarative backend only, as its
description now says, and an event project's response names none, as for
`embedder`. The OpenAPI document is regenerated for these fields only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Adding events and claiming pending derivatives and tombstones depend on
RETURNING, which SQLite added in 3.35: the event insert returns the
events it stored, and each claim returns the row it took. The store's
params refuse an older SQLite runtime, after the check that each session
gets its own connection to one database, and a test raises the minimum
past the runtime to see the refusal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>