Which issue does this PR close?

• Closes Parquet reader returns Binary dictionary values when a supplied schema requests Utf8 #11748
• Part of Epic: Cost-Based Dictionary Encoding datafusion#24111

Rationale for this change

An unannotated Parquet BYTE_ARRAY is inferred as Arrow Binary, even when a supplied reader schema requests Dictionary<K, Utf8>. The dictionary reader currently chooses its value type from the Parquet annotation, so it produces Dictionary<K, Binary>. DataFusion must then discard the encoded representation and rebuild it row by row:

Parquet dictionary page
  values = [b"Chrome", b"Firefox"]
  keys   = [0, 0, 1, 0]
              |
              v
Dictionary<K, Binary>
              |
              | expand keys, validate/convert every row, hash every row
              v
["Chrome", "Chrome", "Firefox", "Chrome"]
              |
              | rebuild dictionary
              v
Dictionary<K, Utf8>

This matters for DataFusion's cost-based dictionary encoding (CBDE) work in apache/datafusion#24111. CBDE can only benefit from the Parquet dictionary when the scan preserves it in the requested logical string type:

Parquet RLE dictionary
        -> Arrow Dictionary<K, Utf8>
        -> DataFusion scan
        -> CBDE can keep the representation when it is beneficial

Without this reader support, the scan pays the expansion and rebuild cost before CBDE can use the dictionary.

What changes are included in this PR?

Decode dictionary pages using their physical Parquet value type, then convert only the distinct values to the value type requested by the supplied Arrow schema:

values: [b"Chrome", b"Firefox"] -> ["Chrome", "Firefox"]
keys:   [0, 0, 1, 0]            -> [0, 0, 1, 0]
                                          unchanged

The converted dictionary values are reused across batches, producing Dictionary<K, Utf8> directly without expanding the keys. Plain-encoded pages continue to use the existing dictionary-building fallback.

The same path handles compatible string/binary and view-type requests, including UTF-8 validation when a binary dictionary is requested as a string dictionary.

Are these changes tested?

Yes. Regression tests cover:

• unannotated binary dictionaries requested as Dictionary<Int32, Utf8> across multiple batches
• preserved keys and shared dictionary values
• invalid UTF-8 input
• annotated UTF-8 dictionaries requested as binary

DataFusion validation

• TPC-H, 0.5% slower end-to-end
• TPC-DS, 1.6% faster end-to-end
• ClickBench, 0.3% faster end-to-end

Are there any significant user-facing changes?

Supplied dictionary schemas now produce columns with the requested compatible string or binary value type. There are no public API changes.