fix(parquet): reuse RowGroupPageIndexReader in FileReaderWrapper layer

[zhf999]

Purpose

Arrow caches the file-level PageIndexReader (ParquetFileReader::GetPageIndexReader()), but
PageIndexReader::RowGroup(i) builds a brand-new RowGroupPageIndexReaderImpl on every call, and
the OffsetIndex/ColumnIndex byte buffer (offset_index_buffer_) is cached inside that instance.
So every new RowGroup(i) call re-issues a real ReadAt for the whole page-index region of the row
group. These reads are not covered by the data-page pre-buffer/range cache, so they are genuine
small I/Os against the underlying file.

Previously each stage of a page-filtered read created its own row-group reader, so for one
partially-matched row group the page index region was read up to three times:

1. FileReaderWrapper::CollectPreBufferRanges() -> ComputePageRanges()
2. FileReaderWrapper::NextPageFiltered() -> ComputePageRanges()
3. PageFilteredRowGroupReader::ReadFilteredRowGroup() (for the per-field OffsetIndex lookups)

This PR makes the row-group page index reader an explicit, reusable input:

• FileReaderWrapper gains GetRowGroupPageIndexReader(row_group_index) plus a
  row_group_page_index_readers_ map that memoizes one reader per row group (including the
  "no page index" negative result), so all stages share the same page-index buffers.
• PageFilteredRowGroupReader::ComputePageRanges() and
  PageFilteredRowGroupReader::ReadFilteredRowGroup() now take the
  std::shared_ptr<::parquet::RowGroupPageIndexReader> from the caller instead of deriving it
  internally from ParquetFileReader::GetPageIndexReader().

Behavior is unchanged: files without a page index still pass a null reader and fall back to the
existing whole-column-chunk path; read results and computed ranges are identical. The only
difference is that the OffsetIndex region of each row group is read and deserialized once per file
reader instead of once per stage.

Tests

No.

API and Format

No changes.

Documentation

No changes.

Generative AI tooling

Generated-by: No.

[lxy-9602]

I’m a bit curious whether row_group_page_index_reader and arrow_file_reader are both intended to be output parameters. If so, should we make them consistent and use shared_ptr for both before putting them into the pool?

[zhf999]

Since arrow_file_reader is a unique_ptr hold by FileReaderWrapper, it cannot be transfer into shared_ptr, we use raw pointer here.

The order of those parameter has been resorted, output parameter pool and arrow_file_reader have been just at the end of this function.

[lxy-9602]

Please adjust comments.

[zhf999]

Done.