Feat: Back MilvusVectorStore collection metadata with SQL collection registry (collection registry stack 5/5) - #1533

Purpose of the change

Move MilvusVectorStore's collection metadata onto the SQL-backed collection registry from #1526, the same swap #1527 made for Qdrant. Milvus kept the same bookkeeping shape (per-namespace memmachine_<ns>__registry Milvus collections with dummy-vector rows) with the same non-atomic read-check-write lifecycle guarded only by per-process locks — and the same cross-process races (#1525). Keeping a bespoke in-Milvus registry was self-containment that was no longer worth its hacks once the shared primitive existed.

Stacked on the concurrency-scope PR (4/5); only the last commit is new to this PR.

Description

milvus_vector_store.py: all __registry machinery is deleted (_REGISTRY_* constants, the dummy-vector registry collections, _ensure_namespace_registry_collection, _get_registry_entry, the hand-rolled _parse_entry, _register_collection, _is_not_found_error). MilvusVectorStoreParams gains a required registry: CollectionRegistry. The lifecycle follows the Qdrant design exactly:

• Create: native-first, register-last — the registry insert is the atomic commit point; a crash or lost race leaves only an empty config-shared native collection, adopted by the next same-config creation.
• Delete: data-first, deregister-last; records written through handles held across the deletion land under the dead generation's partition key — invisible, never resurrected by a re-creation.
• AlreadyExists now holds across processes sharing the registry database; _name_locks remain as in-process serialization only.

Milvus-specific notes: native naming is unchanged (memmachine_{ns}__{sha256(config)}); there is no shard-key machinery — the generationed partition key is only the partition key field value; the native schema's partition-key VARCHAR is resized for generationed keys, and native primary ids ({partition_key}:{uuid}) now embed the generation, keeping ids unique across generations.

Concurrency scope: MilvusVectorStore.concurrency_scope widens from PROCESS to min(CLUSTER, registry scope). Milvus's default Session consistency (process B may read stale data relative to process A's writes) sits within the VectorStoreCollection visibility contract — no read-your-writes is promised — but deployments wanting stronger data-plane visibility should set consistency_level accordingly.

Configuration: MilvusConf.registry_database (required) names a configured relational database entry; the wiring builds the registry milvus_<conf name> via a _build_collection_registry helper now shared with Qdrant. Sample configs, docs, and the installation wizard updated.

Design doc: design/collection_registry_backends.md (the Qdrant doc, extended and renamed).

Breaking changes

• MilvusConf.registry_database is required: existing Milvus users add one line of YAML. Stale memmachine_<ns>__registry Milvus collections are no longer read; as with Qdrant, this is mostly self-healing (native names unchanged, re-creation with an unchanged config re-registers the same native collection), with the same derived-schema drift caveat, and stale registry collections can be dropped manually.

Fixes/Closes

Related to #1525.

Type of change

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

• Unit Test
• Integration Test

Milvus suite (Milvus Lite) runs with a registry over SQLite; the Milvus-side registry white-box test is removed with the machinery it tested; the scope assertion updates to governed-by-registry (MACHINE over the SQLite test registry). DatabaseManager and configuration tests updated for registry_database and the shared registry-builder helper.

Test Results: full server suite 1899 passed; targeted vector-store + resource-manager integration run 555 passed; 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
• I have made corresponding changes to the documentation
• 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
• Any dependent changes have been merged and published in downstream modules

Further comments

With Qdrant and Milvus both on the registry, the remaining PROCESS-scoped stores are the SQLite-backed ones, whose limitation is in-process search-engine state rather than metadata — the registry deliberately does not chase that.