fix: preserve dictionary encoding in to_arrow_batch_reader

[avison9]

Rationale for this change

DataScan.to_arrow_batch_reader(dictionary_columns=("col",)) silently dropped dictionary
encoding — callers got plain string arrays instead of dictionary<values=string, indices=int32>,
with no error or warning. The eager equivalent to_arrow(dictionary_columns=...) worked
correctly. This fixes the streaming path to match.

Before:

result = table.scan().to_arrow_batch_reader(dictionary_columns=("label",)).read_all()
print(result.schema.field("label").type)
# string  ← dictionary encoding silently lost

After:

result = table.scan().to_arrow_batch_reader(dictionary_columns=("label",)).read_all()
print(result.schema.field("label").type)
# dictionary<values=string, indices=int32>  ✓

Root cause: _to_arrow_batch_reader_via_file_scan_tasks built target_schema via
schema_to_pyarrow (which returns plain types), then called .cast(target_schema) on the
RecordBatchReader. ArrowScan.to_record_batches correctly yielded dictionary-encoded
batches, but the cast converted them back to plain types. The fix rebuilds target_schema
with pa.dictionary(pa.int32(), field.type) for each column in dictionary_columns before
the cast, so the encoding is preserved end-to-end.

Are these changes tested?

Yes. Added test_to_arrow_batch_reader_preserves_dictionary_columns in
tests/io/test_pyarrow.py — writes a two-column Parquet file and asserts that
_to_arrow_batch_reader_via_file_scan_tasks returns a dictionary-encoded label column
while leaving id as plain int32.

Are there any user-facing changes?

Yes — to_arrow_batch_reader(dictionary_columns=...) now correctly returns dictionary-encoded
arrays for the requested columns, matching the documented behaviour and the existing to_arrow
path. Please apply the changelog label to this PR — the project has no changelog file/newsfragment
requirement (no CONTRIBUTING.md); release notes are generated from labeled, merged PR titles.

[Fokko]

Thanks for the PR @avison9. I've left some small comments that we should resolve first

[Fokko]

Let's avoid multi-line strings for comments

[avison9]

Noted, that is updated also

[Fokko]

Can we hardcode the int32 for the key? What happens if this is something different than int32?

[avison9]

@Fokko, presently for every code path that actually reaches this line, it will always be int32. But that's because of an internal choice in Arrow's C++ Parquet reader, not something PyArrow documents or guarantees anyway.
If a future PyArrow version ever changed that reader's behavior (e.g., to shrink to int8/int16 for low-cardinality columns, matching dictionary_encode()'s behavior), the hardcoded int32 would silently be wrong again, in exactly the same class of bug this PR is fixing.
The best solution will be to derive the actual dictionary field from the first real batch ArrowScan produces, peek one batch, read its actual index type off first_batch.schema.field(name), and prepend that batch back onto the stream before building target_schema.
I have added this in a new commit, if you can please take a look