bug: pre-computed IVF centroids are only length-checked, so wrong-shaped ones break the build later

LABEL: bug

Description

build_ivf_model accepts user-supplied centroids through IvfBuildParams::centroids (create_index(..., ivf_centroids=...) in Python, withIvfCentroids in Java). Before using them it checks only the flattened length:

if centroids.values().len() != num_partitions * dim {
    return Err(...);
}

Two wrong shapes pass that check:

• Wrong per-row width. 64 centroids of width 8 flatten to exactly the same length as 32 centroids of width 16, so a caller who transposes or reshapes their centroid matrix gets through this boundary and breaks somewhere further into the build, where the message no longer points at the centroids.
• Wrong dtype at the right width. f16 centroids over an f32 column pass, then reach an assignment pair that does not exist for that combination.

Expected behavior

Both are caught at the boundary that already validates the centroids, with an error naming the centroids' value and the column's.

Worth noting for whoever implements it: the check cannot be a plain equality on the element type. An Int8 column is trained as f32 — train_ivf_kmeans_step converts it ((DataType::Int8, L2|Dot|Cosine) => data.convert_to_floating_point()) — and the only assignment pair the kernels implement for it is (DataType::Float32, DataType::Int8), with no (Int8, Int8) arm. So f32 is the expected centroid type for an Int8 column, and a strict equality check would reject the only combination that works.

Lance version

13.0.0-beta.4 (main)

Language binding

Python, Java, Rust

Start at build_ivf_model and the IvfBuildParams::centroids validation, then inspect train_ivf_kmeans_step and the assignment pairs used for supported column and centroid types. Ensure wrong centroid shape and incompatible value type fail at this boundary with errors naming both the centroids' value and the column's; verify the valid f32-centroid path for Int8 columns remains accepted.