Purpose of the change

Make the multi-process capability from #1526/#1527 reachable through the API contract. After those PRs, QdrantVectorStore supports multiple processes managing the same collections — but the VectorStore ABC still said a collection "must be managed by at most one process at a time", so no consumer was permitted to rely on it. This PR replaces that blanket sentence with a declared, per-instance concurrency scope, and states the data-plane contracts that multi-process consumers need to know (#1525).

Stacked on the open-or-create removal PR; only the last commit is new to this PR.

Description

ConcurrencyScope (common/data_types.py): PROCESS < MACHINE < CLUSTER — the widest deployment boundary within which concurrent instances of a component may safely manage the same resources. An IntEnum, ordered by breadth, so the effective scope of a composed system is the min of its parts' scopes.

Declared on the ABCs — VectorStore, SegmentStore, and CollectionRegistry gain an abstract concurrency_scope property, and the one-process-per-collection/partition sentences are rewritten to defer to it: concurrent management of the same collection/partition is safe within the declared scope; beyond it, consumers shard names, as before.

Declared by the implementations:

So a Qdrant store backed by a PostgreSQL registry declares CLUSTER, and one backed by a shared SQLite file declares MACHINE — the deployment can introspect what it is allowed to do instead of relying on out-of-band knowledge.

Data-plane contracts stated on VectorStoreCollection (documentation only; both are pre-existing properties that multi-process deployment makes worth stating):

• Visibility: a returned write is durably accepted but not guaranteed visible to a subsequent query, from this instance or any other — consumers must not build on read-your-writes.
• Authority: stored properties and property filters operate on the collection's own copy of a record, with no freshness guarantee relative to any external source of truth; consumers governed by an external authority (e.g. SQL as the record of access-determining attributes) must re-validate results against it.

Design doc: design/concurrency_scopes.md.

Fixes/Closes

Related to #1525 (contract half of the redesign).

Type of change

• New feature (non-breaking change which adds functionality)

(Adding an abstract property is breaking for out-of-tree VectorStore/SegmentStore/CollectionRegistry implementations, which must now declare a scope.)

How Has This Been Tested?

• Unit Test
• Integration Test

Scope assertions per implementation: qdrant with a SQLite registry declares MACHINE and with a PostgreSQL registry (integration) declares CLUSTER; the SQLAlchemy segment store and config registry assert dialect-based scopes across the sqlite/PG fixture matrix; Milvus and both SQLite stores assert PROCESS.

Test Results: 1897 passed (default run); 585 passed (targeted integration run); 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
• I have commented my code
• My changes generate no new warnings
• I have added unit tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Further comments

Milvus's PROCESS declaration is honest at this point in the stack; the final PR moves Milvus onto the collection registry and widens it to min(CLUSTER, registry scope).