feat: migrate vector SDKs to segment workflow

[Xuanwo]

This follow-up PR moves the Python and Java vector distributed indexing entrypoints and tests to the segment workflow introduced in #6269.

It keeps the core staging-removal refactor in the base PR and limits this change to SDK-facing APIs, JNI/PyO3 glue, and binding-level tests.

[github-actions]

PR Review

Clean migration of Java and Python vector SDK entrypoints to the segment workflow. The test simplification is a big win — removing the manual UUID/field-id/transaction boilerplate makes the distributed indexing tests much more readable.

Issues

P1: inner_commit_existing_index_segments doesn't reload the dataset after commit

In inner_commit_existing_index_segments (blocking_dataset.rs), after commit_existing_index_segments mutates the dataset, load_indices_by_name is called on the same guard. This seems correct for returning metadata. However, the Java-side test asserts dataset.listIndexes().contains(...) on the original dataset handle — does commit_existing_index_segments update the dataset in-place, or does the caller need to reload? If it doesn't update in-place, the final assertTrue in the tests would be relying on stale state (though it might pass if the Rust side mutates the inner Dataset). Worth confirming this is intentional.

P1: segment_template validation may be too strict or too lax

segment_template validates that all segments share the same name, fields, and dataset_version — but it doesn't validate index_version. If segments can have different index_version values, the index_segment_to_metadata function uses the per-segment value (correct), but it's worth documenting why index_version is intentionally excluded from the template consistency check.

Nit

The Python into_builder → builder rename is correct (&self doesn't consume ownership), good catch.

---

🤖 Generated with Claude Code