perf: vectorize raw vector search

[JingsongLi]

What changed

• Batch raw-vector distance scoring with the existing SIMD/cache-blocked SGEMM implementation for four or more unrestricted queries.
• Keep small query batches and sparse include_row_ids searches on the scalar path to avoid matrix setup and unnecessary scoring.
• Replace heap-based O(n log K) raw Top-K maintenance with buffered partial selection, giving amortized O(n) candidate selection and sorting only the final K rows.
• Bound score-matrix chunks to roughly one million elements and store results query-major for contiguous Top-K reads.
• Respect sliced FixedSizeListArray offsets and preserve scalar L2 semantics for non-finite values.

Why

Raw vector search previously computed every row/query distance with scalar loops and maintained a K-sized heap for every query. This left batch queries unable to reuse optimized matrix kernels and paid log K work for each candidate.

Performance

Local release microbenchmark: 8,192 rows, 128 dimensions, L2, K=10. The benchmark compared the previous scalar-distance + heap path with the optimized hybrid path.

Queries	Speedup
1	~1.0x
2	~1.0x
4	1.81-1.84x
8	3.30x
16	4.49-4.62x

Validation

• cargo test -p paimon table::vector_search_builder::tests --lib (79 passed)
• cargo clippy -p paimon --lib -- -D warnings
• cargo fmt --all -- --check
• Matrix/scalar equivalence tests for L2, cosine, and inner product
• Deterministic partial Top-K, sparse candidate, non-finite L2, and sliced Arrow-array coverage

[leaves12138]

The ||a||² + ||b||² - 2·a·b reconstruction is not numerically equivalent to the previous scalar L2 loop for large finite components. I reproduced this with four queries and 128-D vectors: for an exact [1e10; 128] match, this path returns about 4.44e-16 instead of 1.0; a vector differing by 1024 in one component receives the same matrix score, while the scalar path returns about 9.54e-7. This can change Top-K results, not just add a small error. Please use a numerically stable path or fallback when cancellation can dominate, and add large-finite-value coverage.

[leaves12138]

Taking sqrt(query_norm_squared * stored_norm_squared) introduces an overflow that the previous scalar implementation avoided. For an identical [1e15, 0] query and stored vector, both squared norms are finite (1e30), but their product becomes infinity, so this code returns cosine 0 instead of 1. This affects the scalar path too, not only matrix scoring. Please compute the two square roots before multiplying (as before), or otherwise avoid the intermediate product overflow, and add a regression test.

[leaves12138]

LGTM.