Make create session idempotent - #1539

Reviewed the idempotent-create behavior. Note the current diff here is just the create_new_session -> create_new_session_if_not_exist rename; the gate itself already landed on speedkick, so I could not anchor these inline. Both points are about that gate and both cut against the goal in the description ("multiple workers create the same session simultaneously").

1. Concurrent creates still fail rather than converge.

create_new_session_if_not_exist is SELECT-then-INSERT in one plain async_sessionmaker() session at default isolation, and session_key is the primary key. Two workers creating the same session simultaneously both find no row, both INSERT, and the loser gets an IntegrityError. IntegrityError is not a ValueError and is not in RestError.is_known_error, so create_project does not catch it and the caller sees a 500 instead of 201/409.

The self._session_locks[session_key].write_lock() in EpisodicMemoryManager only serializes within one worker, which is the case that already worked. So creation is currently idempotent for sequential retries but not for concurrent ones.

Suggest either an upsert (INSERT ... ON CONFLICT (session_key) DO NOTHING, then re-read and run the same comparison) or wrapping the insert in try/except IntegrityError that falls back into the equality branch. A test issuing two concurrent creates against a real engine would cover it; the tests added with the gate are all sequential.

2. The equality gate compares server-merged config, so it can 409 a semantically identical session.

param_data is the fully merged EpisodicMemoryConf (server defaults merged with the user partial in _with_default_episodic_memory_conf), not the caller's intent, so full-dict == couples idempotency to server-side state.

Two cases that matter for scale out: workers running different builds, where a newly added field with a default makes model_dump(mode="json") produce a superset of the stored dict; and rows written before the pickle-to-JSON migration, which need not round-trip byte-identical to a fresh dump. In both, re-creating an equivalent session raises SessionAlreadyExistsError (409) during exactly the rolling upgrade this is meant to survive.

Comparing a normalized subset, or only the fields the caller actually specified, would be more robust than ==.

3. Naming (this PR's diff).

create_new_session_if_not_exist reads as "create if absent, otherwise no-op", but it raises on any mismatch of configuration / param_data / user_metadata or on a Deleted row. Something like create_or_verify_session or ensure_session matches the actual contract more closely.

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