Deletion-vector length and offset are not validated enough to stop crash or huge allocation attacks

> This issue was reported to the private Apache Iceberg security mailing list. The submitter is being kept anonymous because the report was sent to a private list. After review, the issue is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution.
>
> Note: this submission was generated by AI. Please review its claims and source references carefully before acting on them.

# Summary

Deletion-vector metadata accepts negative or near-2 GiB sizes and
offsets, allowing hostile metadata to trigger crashes or huge
read-time allocations.

# Affected Maven coordinates

* primary shipped client artifact: `org.apache.iceberg:iceberg-data`

# Attacker prerequisites

* ability to make the target process parse attacker-controlled or
semi-trusted table data or metadata
* enough repetition or input size to trigger the unchecked allocation
or crash path

# Impact

* Malicious or corrupted DV metadata can trigger
`NegativeArraySizeException`, invalid seek behavior, or a very large
heap allocation on the read path.
* In practice this is a denial-of-service issue: scanning a table can
be enough to crash or destabilize the worker that evaluates the
deletion vector.

# Proof status

Source review only. The issue is visible directly from source.

# Key source references

* org.apache.iceberg.data.BaseDeleteLoader
* org.apache.iceberg.FileMetadata

Start by reading org.apache.iceberg.data.BaseDeleteLoader and org.apache.iceberg.FileMetadata to trace how deletion-vector lengths and offsets are parsed and used during reads. Confirm the behavior for negative and near-2 GiB values, then add coverage showing malformed metadata is rejected without a crash, invalid seek, or huge allocation.

Written by the indexing model from the issue text.