Include vocabulary and domain ID in NearestConceptMatch

[nicoloesch]

Summary

• Closes Add 'domain' and 'vocabulary_id' fields into return values of embedding search #44

NearestConceptMatch now carries domain_id, vocabulary_id, and is_active alongside the existing is_standard, and all three embedding backends (pgvector, sqlite-vec, and the FAISS sidecar) populate them consistently. Previously only is_standard was returned by KNN queries, whereas domain_id/vocabulary_id weren't exposed at all. is_active was documented as CDM-enriched but actually already got populated during ingestion.

These four fields all come from the embedding table's own filter columns (written from the CDM at ingestion time), so they're now always populated regardless of whether an omop_cdm_engine is configured for the read interface. concept_name remains the only field that requires a CDM engine at query time to "save" some storage.

As part of this, ConceptEmbeddingRecord.is_valid no longer defaults to True. It's now required, matching is_standard, so every call site has to state a concept's validity explicitly instead of silently inheriting a default. This was already done in production code and only had to be adapted in test sites.

Checklist

• Applied exactly one label (breaking, feature, fix, dependencies, or chore)
• Tests pass locally (uv run pytest -q)
• Lint passes (uv run ruff check .)

[gkennos]

add at least one test that asserts end to end that new fields are populated on returned matches