bug: IVF_HNSW_PQ recall assertions fail intermittently because k-means init is unseeded

[jackylee-ch]

test_create_ivf_hnsw_pq_4bit and test_create_ivf_hnsw_pq_multivec fail their
assert_ge!(recall, 0.5) check intermittently, on main as well as on PRs.

Observed in the last day:

where	test	recall
main 91aee6f91, linux-build	test_create_ivf_hnsw_pq_4bit::case_3_dot	0.4
PR #8431, mac-build (stable)	test_create_ivf_hnsw_pq_4bit::case_3_dot	0.4
PR #8755, linux-arm	test_create_ivf_hnsw_pq_multivec	0.3

Each run was otherwise green (e.g. 3146 passed, 1 failed), and the failing test
differs by runner, so this is not a regression from any one change.

The input is already deterministic: make_seeded_vector_batch
(rust/lance/src/index/vector/ivf/v2.rs:2615) pins Seed::from(42). The variance
comes from index training instead — rust/lance-index/src/vector/kmeans.rs:930
reads

// TODO: use seed for Rng.
let mut rng = SmallRng::from_os_rng();

so centroid initialization differs every run. With K = 10 the recall metric
moves in steps of 0.1 and the threshold is 5 of 10 neighbours, so a slightly
worse set of centroids flips the assertion.

Threading a seed through KMeansParams for the test path would make these
deterministic, which the existing TODO already anticipates. Lowering the
threshold would also stop the failures but would weaken the check.

[jackylee-ch]

Two more hits since filing, both on PRs whose changes are in unrelated crates:

where	test	recall
#8765, windows-build	test_build_ivf_pq_4bit::case_2_cosine	0.4
#8752 run, mac-build (stable)	test_create_ivf_hnsw_pq_4bit::case_3_dot	0.4

So the affected set is wider than the two tests above — test_build_ivf_pq_4bit shares the same assert_ge!(recall, 0.5) at v2.rs:2740 and fails the same way, which fits the unseeded-centroid explanation rather than anything HNSW-specific.

[LuciferYang]

Rate measured on current main (48eb6ffc1, aarch64-apple-darwin, --profile ci): test_create_ivf_hnsw_pq_multivec fails 4 times in 150 runs of the prebuilt test binary, with the same assertion and recall values of 0.3 and 0.4. So this is roughly 2.7% per job that runs -p lance --lib, and every platform job runs it, which is why unrelated PRs keep collecting one red job each.

Two of mine did today: #8869 on mac-build (stable) and #8870 on linux-arm, both this test, both on changes that cannot reach the IVF-HNSW-PQ path (a RabitQ storage validation and a test-only hamming change).

#8767 threads the seed through and has been mergeable since the 26th.