fix(spec): decode pre-1.0 deletion-vector metas via the writer schema

[jackylee-ch]

decode_nullable_dv_ranges read the _DELETIONS_VECTORS_RANGES item record
positionally and always consumed a _CARDINALITY union index. Java added that
field in 1.0.0 (#4699); 0.8.0-0.9.x declared the item as RowType.of(STRING, INT, INT), so on an older file the decoder steals the next item's bytes and
IndexManifest::read_from_bytes fails with avro cursor: negative bytes length: -49. The serde reader reads the same bytes fine, and the read is also
on the commit path (read_prev_index_entries), not just scans.

Fix: walk the writer's own nested field list, as
decode_nullable_binary_table_stats does, peeling array<["null", record]> to
reach the item, since array items keep their union. An item without f0 is
rejected rather than defaulted, f0 being the map key.

An index manifest is rewritten only by a commit that changes an index file, so
such files are still live.

[JingsongLi]

Does this requirement come from a real production environment?

[jackylee-ch]

Not directly from a production issue. I found this while testing compatibility with tables written by older Paimon versions.

[JingsongLi]

@jackylee-ch Why is it still necessary to maintain compatibility with formats from a few years ago?

[jackylee-ch]

Agreed, 0.8/0.9 support on its own would not be worth it — that table is just how I hit it. As I read IndexManifestEntrySerializer, this record's field list is deliberately not fixed: "Do not change when adding nullable fields. Old manifest readers skip unknown fields." Java resolves the record by name against the OCF's writer schema, so an item without _CARDINALITY reads as null; ours reads that union index by position, so the gap is on our side, not Java's. decode_nullable_global_index guards _SOURCE_META the same way (#515). Happy to drop the version framing from title and body.