feat(java): expose aggregate index fragment coverage

[everySympathy]

Why

Java callers can inspect each segment fragment list today, but must materialize every fragment id in the JVM to calculate logical index coverage. This is expensive for large datasets and does not expose the serialized bitmap size.

What

• add an aggregate IndexFragmentCoverage result to Rust IndexDescription and Java IndexDescription
• union all physical segment bitmaps before calculating covered, current, missing, and stale fragment counts
• report the exact run-optimized manifest serialization size of all segment bitmaps
• expose a Java coverage ratio without copying the raw bitmap
• preserve compatibility for external Rust IndexDescription implementations and existing Java constructors

Tests

• cargo test -p lance-table test_fragment_bitmap_serialized_run_optimized
• cargo test -p lance test_describe_indices_rows_indexed_stale_bitmap_fragment
• cd java && ./mvnw test -Dtest=DatasetTest#testDescribeIndicesByName
• cargo clippy --all --tests --benches -- -D warnings

[zhangyue19921010]

Do we need to exclude system indexes

[everySympathy]

Good point. System indexes should remain visible in describeIndices for compatibility, but their bitmaps do not represent normal data-index coverage (__lance_frag_reuse tracks remapping participation, while __mem_wal may have no bitmap). Fixed in e6c513d at the Rust core layer: all system indexes now return no fragment coverage, so JNI exposes Optional.empty(). Added regression coverage for both bitmap-bearing frag reuse and bitmap-less mem-wal indexes.

[lance-gatekeeper]

✅ Gate recommendation: approve.

System indexes remain discoverable without reporting misleading data-fragment coverage, and ordinary index summaries retain their aggregate coverage and no-expansion behavior.