perf: add benchmark for distributed vector merge finalization

[Xuanwo]

This adds a dedicated benchmark for distributed vector index finalization and a small query-side metric to count find_partitions calls. Together they give us a baseline for analyzing the current single-node merge bottleneck and for evaluating future segmented-index work.

As context, the new distributed_merge_only_ivf_pq benchmark already shows that finalize cost grows much faster than input bytes as shard count and partition count increase. In the local filesystem benchmark, the mean finalize time grows from about 64 ms at 8 shards / 256 partitions to about 2.87 s at 128 shards / 1024 partitions.

---

Based on this benchmark, I noticed that our current logic performs poorly as the number of shards increases.

[github-actions]

ACTION NEEDED
Lance follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

For details on the error please inspect the "PR Title Check" action.

[github-actions]

PR Review

Clean PR — benchmark is well-structured and the metric addition is minimal and well-tested.

One minor issue

Potential division by zero in write_case_metadata (line ~338 of the benchmark):

partial_aux_bytes_per_shard: fixture.partial_aux_bytes / fixture.partial_dir_count as u64,

If partial_dir_count is 0 (e.g., fixture building failed silently or was skipped), this will panic. Consider using .checked_div().unwrap_or(0) or guarding against it. Low severity since this is benchmark-only code, but it could make debugging confusing if a fixture doesn't build properly.

Looks good

• The find_partitions_calls metric is a clean addition with proper test coverage across all relevant test cases.
• Benchmark design with fixture caching and iter_batched for isolation is solid.
• No concerns with dependencies — all are already in the workspace.

🟢 LGTM with the optional nit above.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[BubbleCal]

LGTM

[BubbleCal]

believe we have such helper function already, maybe just need to change its visibility

[BubbleCal]

how about changing this to FIND_PARTITIONS_ELAPSED_METRIC?
we may introduce some optimizations for find_partitions in the future, the number of calls can't prove that