[enhancement](scan) Optimize Parquet V2 predicate filtering and fixed-binary decimal decoding

[Gabriel39]

What problem does this PR solve?

Related PR: #66360, #66379

Problem Summary:

This PR brings two complementary Parquet V2 optimizations from branch-4.1 to master:

1. reduce predicate-filtering overhead and correctly propagate late runtime filters through the scanner and reader layers;
2. avoid unnecessarily decoding same-scale fixed-binary decimals through Int256 when their physical width permits a narrower native type.

Parquet V2 predicate filtering (#66360)

• Keep identity selection-vector state implicit and compact selected rows in bulk.
• Retain the selection scratch high-water mark across scanner batches and specialize the first compaction from implicit identity.
• Refresh late runtime-filter requests at safe row-group boundaries.
• Re-run footer-statistics pruning and reset adaptive predicate state for unopened row groups after a refresh.
• Preserve real COUNT(*) carrier values while runtime filters are pending.
• Initialize refreshed JNI predicates and attribute refresh work to TableReader, FileReader, and Parquet profiles.
• Preserve Hudi and Paimon child-reader predicate state.
• Remove query-scoped dictionary-filter cache state.
• Share immutable VDirectInPredicate pruning materialization across split-local expression clones.
• Add correctness-checked selection-vector and direct-IN lifecycle microbenchmarks.

Fixed-binary decimal decoding (#66379)

• Decode same-scale Parquet FIXED_LEN_BYTE_ARRAY decimals with int32_t, int64_t, or Int128, selected from the physical width, instead of always using Int256.
• Use unaligned full-width big-endian loads for 4-, 8-, and 16-byte values while preserving sign extension for shorter widths.
• Validate target precision before narrowing and preserve both permissive and strict conversion behavior.
• Keep rescaling and wider values on the existing Int256 path.
• Cover positive and negative precision boundaries, shorter signed inputs, strict rollback, permissive null marking, and the complete int32 source domain.

Performance

The results below come from the original branch-4.1 PR benchmarks in #66360 and #66379. This PR applies the same implementation to master; the performance benchmarks were not re-run as part of this forward-port.

Selection-vector processing

The benchmark validates every surviving original row ID after the timed region. It used the same Clang -O3 -DNDEBUG -mavx2 benchmark source for the branch base, the pre-fix PR, and the final implementation, with one pinned CPU, three warmups, eight adjacent A-B-B-A quartets, and at least 0.3 seconds per invocation. Negative percentages are improvements.

Operation	Final selectivity	Final vs pre-fix PR	Final vs branch base
Identity initialization	100%	-15.23%	-99.12%
Row filter	1%	-24.23%	-23.76%
Row filter	50%	-16.10%	-34.50%
Row filter	90%	-45.91%	-45.95%
Row filter	100%	-31.72%	-17.32%
Successive filters	1%	-33.25%	-35.79%
Successive filters	50%	-29.80%	-35.10%
Successive filters	90%	-25.27%	-25.16%
Successive filters	100%	-24.93%	-23.72%

Compared with the branch base, identity initialization improved by 99.12%, row filtering improved by 17.32%-45.95%, and successive filtering improved by 23.72%-35.79%. All final-vs-base paired-ratio CVs were at most 5.85%.

Direct-IN expression lifecycle

FileScannerExpr/direct_in_clone_prepare_open isolates deep-clone, prepare, and open for an already prepared direct-IN runtime filter. Set construction and the original fragment prepare/open are outside the timed region. The shared and forced-rematerialization implementations ran in the same Release binary on one pinned CPU, with 10 repetitions and at least 0.5 seconds per repetition.

IN values	Rematerialize median	Shared median	Speedup
128	207.470 us	1.634 us	126.9x
1,024	1.674 ms	1.642 us	1,019.5x
8,192	13.514 ms	1.672 us	8,082.2x
65,536	108.337 ms	1.650 us	65,663.1x

The shared path remains approximately constant because split-local clones reuse immutable pruning state instead of rebuilding it for every split.

Reader-level regression guardrail

The Parquet reader benchmark covered nullable INT32 predicate scans with a lazy payload for both PLAIN and dictionary encoding. Across 1%, 10%, 50%, and 90% selectivity, CPU-time changes ranged from -1.34% to +1.41% with mixed signs, so it did not detect a material aggregate reader-level regression.

Fixed-binary decimal decoding

The benchmark decoded 65,536 values per iteration through DataTypeDecimalSerDe::read_column_from_parquet, pinned to one CPU, with three warmups followed by 10 repetitions in A-B-B-A order.

Target / physical width	Before median CPU	After median CPU	Speedup	CPU reduction
Decimal32 / 4 bytes	1,359,514 ns	88,527 ns	15.36x	93.49%
Decimal64 / 8 bytes	1,634,757 ns	90,609 ns	18.04x	94.46%
Decimal128 / 16 bytes	2,206,272 ns	152,823 ns	14.44x	93.07%

The optimized path was 14.44x-18.04x faster in this benchmark, reducing CPU time by 93.07%-94.46%. The benchmark host was heavily loaded and CPU frequency scaling was enabled, so the exact ratios are noisy; however, the before/after median ranges did not overlap in any A-B-B-A stage.

Validation on master

• 705 filtered ASAN BE unit tests from 53 suites passed, covering Parquet V2, FileScannerV2, TableReader, Hudi/Paimon/JNI readers, SelectionVector, direct-IN pruning, and decimal SerDe.
• BE formatting and strict clang-format checks passed.
• git diff --check passed.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[Gabriel39]

run buildall

[Gabriel39]

/review