feat(table): decode the BucketVectorSearchSplit byte form

[JunRuiLee]

Purpose

apache/paimon#9386 gave BucketVectorSearchSplit a byte form so a reader outside the JVM can read it. This is that reader: a Java planner enumerates bucket splits -- the ANN current-segment decision needs the bucket's complete active-file set, which an ordinary table scan split does not carry -- and dispatches each to a worker running this crate.

Decode only. The writer that produced the fixtures has merged, as 088d4880ff. Part of #514.

i64 magic = "PKVSPLIT"; i32 version = 1
DataSplit                             // DataSplit#serialize
i32 payloadCount; IndexFileMeta*      // IndexFileMetaSerializer#serializeList
i32 rangeFileCount; rangeFile*
  rangeFile = utf fileName, i32 rangeCount, (i64 from, i64 to)*

A payload is a BinaryRow of IndexFileMeta.SCHEMA. The DataSplit already had a decoder, and nested rows reuse what BinaryTableStats does inside DataFileMeta, but two element layouts were missing:

• array<int> (_EXTRA_FIELD_IDS): 4-byte slots, so neither the existing bigint/string readers nor the bound check they share applies.
• array of rows (_DELETIONS_VECTORS_RANGES): elements are addressed like variable-length fields, so the reader returns element slices for the caller to decode at its own arity.

VERSION pins the nested layout too, since IndexFileMetaSerializer carries no version. The DataSplit is the exception: it carries its own.

Java re-checks little on the way back in, so this validates what a reader of untrusted bytes has to: row ranges against the data file they name, global index and source metadata present, counts and lengths bounded by what can follow, no trailing bytes, and a malformed nested structure reported as invalid data rather than as an internal fault. Where the writer's layout is exact the checks are exact rather than permissive, so nothing is accepted that the writer could not have produced.

Tests

Two fixtures dumped from the Java writer plus unit tests for the array readers. The first carries non-empty rows and stats, read back as values. The second covers deletion vector ranges (including a null cardinality), a second payload, and all-optionals-absent; without it both new readers would go untouched by real bytes. The rest is hostile input.

Fixtures are copies and the Java side keeps none of its own, so a change there has to be carried over by hand. Both payloads of the second fixture share one _SOURCE_META, so the test cannot prove one payload's was not read off the other.

Notes

• BucketVectorPayload rather than spec::IndexFileMeta, which models the manifest form: no external path, row count narrowed to i32. Aligning that type with the schema looks worthwhile but touches every construction site.
• Existing DataSplit decoder behaviour left alone, since it predates this and every split path reaches it: absent totalBuckets becomes 1, isStreaming = true and snapshot -1 are rejected, and only versions 8 and 9 are read where Java reads 1 through 9.
• deserialize_binary_array_str has the aliasing gap the new array-of-rows reader rejects. Pre-existing, with other callers, so it is left for its own change.

[JingsongLi]

+1