fix: support hamming distance in IndicesBuilder

[jmhsieh]

Summary

• IndicesBuilder rejected uint8 vector columns and didn't include "hamming" in its allowed distance types, even though the underlying Rust train_ivf_model supports hamming via k-modes
• Relaxes _normalize_column to accept unsigned integer value types alongside floats
• Adds "hamming" to _normalize_distance_type's allowed list
• Adds test_ivf_centroids_hamming test with uint8 vectors

Test plan

• test_ivf_centroids_hamming — end-to-end IVF training with uint8 vectors and hamming distance
• Existing test_ivf_centroids tests still pass (float path unchanged)

🤖 Generated with Claude Code

[github-actions]

PR Review

Clean, focused change. The Rust layer already validates that uint8 vectors are only used with hamming distance (train_ivf_model match + validate_distance_type_for), so relaxing the Python-side check is safe — invalid combos like uint8+L2 will get a clear error from Rust.

One minor suggestion:

In _normalize_column, unsigned integer columns are now accepted regardless of the distance type (which isn't known yet at column-validation time). This is fine because Rust validates it downstream, but a brief comment in _normalize_column noting that the dtype/distance-type compatibility is enforced later in train_ivf would help future readers understand why the check is intentionally loose:

# Unsigned integer types (e.g. uint8) are accepted here for hamming distance;
# dtype/distance-type compatibility is validated downstream in train_ivf.

Otherwise LGTM — test coverage is good, docstrings are updated, and the change is minimal.

[Xuanwo]

Thank you!