Extend batch vector queries to ANN and indexed search

[BubbleCal]

Parent: #6820
Depends on: #6821
Linear: https://linear.app/lancedb/issue/OSS-924/extend-batch-vector-queries-to-ann-and-indexed-search
Linear parent: https://linear.app/lancedb/issue/OSS-922/vector-search-performance-optimization-roadmap

Goal

Extend batch query support beyond flat KNN so indexed vector search can handle multiple query vectors in one request without falling back to repeated single-query planning.

Scope

• Define how batch query execution should flow through IVF/PQ/RQ/HNSW-style indexed paths.
• Preserve per-query top-k semantics and result grouping.
• Avoid rebuilding or re-reading per-query state when index-level state can be shared across the batch.
• Decide whether every index type must support batch query immediately or whether unsupported index types should explicitly fall back / error.
• Keep recall behavior equivalent to repeated single-query execution for the same parameters.

Acceptance criteria

• Indexed batch query tests compare against repeated single-query indexed search for at least one IVF-based index.
• Query planning does not silently disable the index solely because query_count > 1.
• Benchmarks report latency and QPS for repeated single-query indexed search versus indexed batch search.
• Unsupported index types have explicit behavior and tests.

[sezruby]

Hi @BubbleCal — I see this is assigned to you; is it open for a contribution? I've opened #7640 for the indexed batch path (also mirrored on my fork at sezruby#2).

Approach: a shared-scan IVF path (ANNIvfBatchExec + IVFIndex::search_partitions_batch) that reads each probed partition's storage once and scores all query vectors against it, with the prefilter built once and shared across the batch. IVF_FLAT/PQ/SQ/RQ take the shared path; HNSW / refine_factor / mixed indexed+unindexed scans fall back to per-query indexed search. Per-query top-k and query_index grouping are preserved, and results are verified equal to repeated single-query search.

One scoping question against the acceptance criteria: the shared path is gated to fixed nprobes (minimum_nprobes == maximum_nprobes). With adaptive nprobes the single-query path applies an early_pruning floor + late-search expansion that a static batch scan would diverge from (I have a repro), so those queries currently fall back to repeated single-query planning. A batched early/late search would close that gap. Would you prefer fixed-nprobes-first with adaptive as a follow-up (what #7640 does), or the full batched-adaptive path in one PR?

Happy to adjust the scope based on your preference.