feat: Add Vector Store Support in Valkey & Elastic Search

[Manisha4]

What this PR does / why we need it:

What this PR introduces:

New APIs :
- retrieve_online_documents_v2 — single-signal vector kNN on Elasticsearch and Valkey online stores, with per-query distance-metric override - retrieve_online_documents_v3 — multi-signal retrieval with configurable fusion strategies and reserved output fields

V3 fusion strategies (Elasticsearch)

• AUTO — single-signal runs as native kNN; multi-signal routes to RRF
• RRF — Reciprocal Rank Fusion with tunable rrf_k (rank-window parameter)
• WEIGHTED_LINEAR — per-signal weights, with validation that every signal has a weight
• VECTOR_ONLY — explicitly drop any text signal, run pure vector kNN (basic-license safe)

V3 reserved output fields

• final_score — the backend's ranking score (ES _score, higher = better; Valkey distance, lower = better)
• signal_scores — per-signal score breakdown (populated for single-signal queries)

V3 input validation

• Unknown embedding keys → clear ValueError listing available vector fields
• "embedding" magic-key auto-resolves on single-vector FVs; errors on ambiguous multi-vector FVs
• Reserved-name collision detection (callers can't shadow final_score / signal_scores)
• Missing signal weights for WEIGHTED_LINEAR → ValueError before ES call
• Whitespace-only query_string normalized to None

Elasticsearch backend enhancements

• Quantization support: int8_hnsw, int4_hnsw, bbq_hnsw, and matching flat variants (75–97% memory savings)
• HNSW tuning: hnsw_m, hnsw_ef_construction configurable per store
• rescore_oversample for accuracy recovery on quantized indices (wired through V2 and V3)
• use_native_knn toggle — native kNN (approximate, fast) or script_score (exact, backward compat)
• knn_num_candidates_multiplier for per-query HNSW breadth tuning
• Dimension-based validation: int4 requires even dims; BBQ requires ≥ 64 dims; all validated at feast apply time
• Hybrid queries built via ES's native retriever API (ES 8.14+)

Valkey backend enhancements (V2)

• Vector index creation via FT.CREATE during online_write_batch
• Two-step retrieval pattern: FT.SEARCH for kNN + pipelined HMGET for feature hydration
• Project scoping — project tag field on every hash, filtered at query time, prevents cross-project leakage on shared clusters
• V3 calls with multi-signal fusion gracefully degrade to single-vector kNN with a warning (Valkey Search doesn't support native fusion)

Signal-scores utility

• Shared encode_signal_scores / decode_signal_scores helpers in infra/online_stores/_signal_scores.py for consistent score-dict encoding across backends

Infrastructure

• V3 API plumbed through FeatureStore, Provider, PassthroughProvider, RemoteProvider, and the OnlineStore base class so additional backends can adopt V3 without further framework changes

Correctness fixes rolled in

• Ranked-row ordering fix (V3) — retrieval results returned in backend rank order instead of lexicographic entity-key order
• rescore_oversample wired to V3 retrievers — quantized-index queries now actually receive the rescore step the config promises
• ES correctness/perf/robustness fixes, ES integration test fixes, vector-field identification fix

Backwards compatibility

- V1 and V2 APIs remain functional; V3 is additive

• Defaults preserve legacy behavior (use_native_knn=False, no quantization, etc.)

Known runtime dependencies

• Elasticsearch 8.14+ for V3 RRF; 8.19+ for linear retriever
• Elasticsearch fusion strategies (RRF, linear) require a trial / platinum / enterprise license; V3 on basic-license clusters is limited to single-signal retrieval (VECTOR_ONLY), equivalent to V2 plus V3's validation and output improvements
• Valkey Search module required on the Valkey cluster for vector support

Which issue(s) this PR fixes:

Misc