Make pgvector and the model registry schema-aware; fix sqlite-vec's engine reconstruction

[nicoloesch]

Depends on AustralianCancerDataNetwork/omop-alchemy#57. Requires pyproject.toml version update for oa-configurator, orm-loader, and omop-alchemy

Summary

What changed

-table_exists, index management, and model-registry lookups all ignored the connection's configured schema, so a non-default-schema pgvector deployment silently read/wrote the wrong tables.

• Fixed via oa-configurator's schema-aware primitives, with new non-default-schema regression coverage.

• create_sqlitevec_engine() no longer rebuilds its own engine from a bare path

  • it now wraps an already-resolved Engine directly.

• The model registry now lives in its own reserved schema (MODEL_REGISTRY_SCHEMA), independent of whichever schema the embedding store itself resolves to

• The registry's own "registry" schema tag is now registered via register_reserved_schema_tag()

• resolve_registry_schema() renamed resolve_registry_physical_schema(), matching the physical_schema_of naming used stack-wide.

• ReadOnlyEmbeddingStore's schema/self.schema (in read_only.py) renamed physical_schema throughout to prevent ambiguity between a schema tag and a physical schema

• Adopts physical_schema_of stack-wide.

• New test_schema_provenance_guard.py: registry-drift and primary-schema-drift regression tests against live Postgres.

Removed

• PGVectorEmbeddingBackend.from_db_url() (dead code, zero callers).

Breaking changes

• create_sqlitevec_engine()'s signature changed from db_path_str to engine: Engine

Checklist

• Applied exactly one label (breaking)
• Tests pass locally (uv run pytest -q): 151 passed, 5 pre-existing unrelated failures