Fix duplicate deletion vectors when filter pushdown clones the multi file list

[NiclasHaderer]

Some Iceberg DML operators (IcebergDelete) capture a reference to the IcebergMultiFileList in the scan's bind data at planning time. If filters are pushed into the scan afterwards (e.g. runtime join min/max filters during UPDATE ... FROM), PushdownInternal creates a clone with empty delete-state maps, and the scan reads existing deletes into the clone. FlushDeletes then consults the original's empty map, misses the table's existing deletion vector, and neither invalidates its manifest entry nor merges its positions. The commit ends up with two DVs for the same data file, and the next read fails with Table is corrupt, two or more deletion vectors exist for the same referenced_data_file.

Fix: keep positional_delete_data and equality_delete_data in a shared_ptr and alias them in PushdownInternal, so a list and all its pushdown clones share one delete state regardless of which instance scans and which one flushes. Filter state stays per-instance. Sharing needs no additional locking because the accesses are ordered by the pipeline: deletes are written while the scan runs, and FlushDeletes only reads them in the sink's Finalize, which the scheduler fires after the scan has completed.

[Tishj]

This might be a different solution to #1038

Could you include the test from that PR here as well to verify?

[NiclasHaderer]

Just added the test and ran it locally. Seems to work

[Tishj]

I feel like there might be a lifetime issue here, because the map eventually references a IcebergManifestEntry entry, which can be owned by this initial instance and isn't properly transferred

I think we just need to rework this a bit to group all of the gathered metadata into a shared instance.
The member that is of significance to this issue is likely the mutable vector<IcebergManifestListEntry> committed_delete_manifests;