Feat: Remove open-or-create semantics from VectorStore and SegmentStore (collection registry stack 3/5) - #1530

Purpose of the change

Remove adopt-on-exists (open_or_create_*) semantics from the storage lifecycle APIs. With collection management becoming multi-process-capable (#1524, #1525), the long-term shape is a strict control plane — create fails on an existing resource, open fails on a missing one — with ensure semantics confined to bootstrap composition at the call sites that genuinely need it. An audit found exactly two consumers of these methods, neither of which needs adopt-on-exists as a primitive.

Stacked on #1527 (its qdrant lifecycle is what this PR edits); only the last commit is new to this PR.

Description

Removed from the ABCs and every implementation:

• VectorStore.open_or_create_collection (Qdrant, Milvus, SQLite, sqlite-vec) and VectorStoreCollectionConfigMismatchError — the method was its only raiser.
• SegmentStore.open_or_create_partition (SQLAlchemy) and SegmentStorePartitionConfigMismatchError, along with the implementation's mismatch-check helper.

EventMemory itself has no ensure semantics (it receives already-opened handles), so nothing changes there.

Consumers restructured to strict create/open with concurrent-creation tolerance:

• semantic_manager.get_semantic_storage: open; on miss create (suppressing AlreadyExistsError — a concurrent creator winning is fine) and re-open.
• service_locator (episodic event backend): the partition path gets the same open -> create -> open shape its collection path already used; the collection path additionally gains AlreadyExistsError tolerance, which multi-process deployments make reachable.

Config-mismatch detection goes away with the methods: with strict create, a caller that loses a creation race adopts the winner's collection via open, and its config is available on the handle for any consumer that wants to enforce its own equality policy. No current consumer does — configs are derived from code, not user input, at every call site.

The collection registry's get_or_register (from #1526) is unaffected: it is the registry-level primitive these APIs no longer surface.

Design doc: design/storage_lifecycle_strictness.md.

Fixes/Closes

Related to #1524 / #1525.

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (does not change functionality, e.g., code style improvements, linting)

How Has This Been Tested?

• Unit Test
• Integration Test

Removed the open_or_create-specific tests; remaining usages in test suites converted to explicit create+open helpers. The segment-store concurrency tests now create their partition once up front (the previous version exercised concurrent adopt-on-exists). Semantic-manager wiring test updated to the open -> create -> open flow. Full server suite plus the qdrant/registry/segment-store integration matrix pass.

Test Results: 1891 passed (default run); 574 passed (targeted integration run: qdrant http/grpc/distributed containers + PostgreSQL); ruff check, ruff format --check, ty check packages clean (no new diagnostics).

Checklist

• I have signed the commit(s) within this pull request
• My code follows the style guidelines of this project (See STYLE_GUIDE.md)
• I have performed a self-review of my own code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes

Further comments

EpisodicMemoryManager.open_or_create_episodic_memory is deliberately untouched: it is an in-process instance-cache accessor (get-or-construct a session's memory object), not a durable-storage ensure, so it is a different kind of API. Flagging it in case the naming alignment is wanted separately.