fix(table): align Data Evolution row-range pruning with Java

[jerry-024]

Summary

Align Data Evolution row-range manifest pruning with Java two-stage direct intersection. This avoids retaining unrelated manifests and data files solely because their ranges belong to an overlapping transitive component, while preserving Java-compatible missing-provider semantics.

Changes

• reuse RowRangeIndex normalization for sorted, merged query ranges
• prune each manifest by its own [minRowId, maxRowId] envelope and each merged live entry by its actual row range
• fail open per manifest or entry when row-range metadata is missing or invalid
• apply ADD/DELETE netting before entry pruning and keep provider/read-type grouping in the later Data Evolution planning stage
• NULL-fill missing nullable providers and reject missing non-nullable providers

Testing

• focused regressions for overlapping manifest envelopes and entry ranges
• fail-open coverage for missing, one-sided, invalid, zero-count, and overflowing ranges
• Data Evolution end-to-end coverage for rolled BLOB/vector pruning and nullable gap NULL filling
• real BTree lookup coverage from an ID predicate to an exact row range and nullable BLOB NULL filling
• row-id pushdown rejects a missing non-nullable provider
• Data Evolution reader module: 68 passed
• cargo fmt --all -- --check and git diff --check

Notes

No planner memory option, temporary spill files, iterative candidate expansion, or additional scan trace fields are introduced.

[JingsongLi]

[Blocking] Null-fill partially uncovered ranges for nullable providers

retain_manifest_entry_row_ranges may retain a nullable BLOB/vector provider because it overlaps one selected range, even though other selected ranges fall into a gap in that provider.

For example, consider a normal anchor covering [0, 5], a nullable provider covering only [0, 1], and selected ranges [1, 1] and [3, 3]. The provider is retained because it overlaps [1, 1], so the source plan assigns the column to that provider. open_source_stream then rejects [3, 3] as uncovered and returns DataInvalid. However, selecting only [3, 3] prunes the provider completely and correctly returns NULL.

This makes the nullable missing-provider behavior inconsistent: adding a covered row turns a valid NULL-filled query into an error. Please make BLOB and vector sources emit NULL/placeholders for uncovered selected ranges, rather than NULL-filling only when the entire provider is absent. Please also add end-to-end tests covering mixed provider-covered and provider-gap ranges for both BLOB and vector columns. The existing test_selected_blob_fallback_rejects_uncovered_non_deleted_range currently codifies the erroneous behavior and should be updated accordingly.