[core] Use full-range anchor as row representative in DE read-type pruning

[LuciferYang]

Purpose

close #9898

When a data-evolution row-id-range group has no file that writes the query's projected columns, read-type pruning keeps one file as a row-count representative so the reader emits the right number of NULL-filled rows. The representative was group.get(0), which can be a blob or vector-store file. Those files cover only a sub-range of the group's row ids, so the split silently emitted fewer rows than the group actually contains. This uses retrieveAnchorFile instead, which returns a full-range normal data file and never a blob or vector-store file (the same primitive the deletion-vector anchor path already relies on).

The pruning core is extracted into a @VisibleForTesting static method so the representative choice can be pinned by a unit test with a blob file ordered first in the group. The filter-field logic added by #9872 is preserved: the instance method still folds in the fields referenced only by the filter and passes them to the static method, so the set of kept files is unchanged.

Tests

DataEvolutionFileStoreScanTest#testReadTypePruningKeepsAnchorAsRowRepresentative builds a group of a blob file covering rows 0-1 (ordered first) plus two full-range normal files covering rows 0-9, with a readType referencing a column no file writes. It asserts the representative is the full-range normal file. Against the old group.get(0) fallback the representative is the blob file, so the assertion fails.