[opt](parquet) accelerate fixed binary decimal decoding

[Gabriel39]

Proposed changes

• Decode same-scale Parquet FIXED_LEN_BYTE_ARRAY decimals with an int32_t, int64_t, or Int128 source 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 the target decimal precision before narrowing, preserve permissive/strict conversion behavior, and keep rescaling and wider values on the existing Int256 path.
• Add regression coverage for positive and negative precision boundaries, shorter signed inputs, strict rollback, permissive null marking, and the complete int32 source domain.

Validation

• ASAN BE unit tests: 8 tests from DataTypeSerDeParquetTest passed.
• Release microbenchmark: 65,536 values per iteration through DataTypeDecimalSerDe::read_column_from_parquet, pinned to one CPU. Each stage used 3 warmups followed by 10 repetitions in ABBA 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 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 ABBA stage. A final optimized-build smoke run measured median CPU times of 95,077 ns, 94,635 ns, and 145,417 ns with CPU CVs of 0.41%, 1.76%, and 0.64%, respectively.

[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

[github-actions]

Opinion: approve.

I completed a static review of both changed files at head 57c70283cd35d107bfddc74278d3f0ba7158d020. I found no blocking or non-blocking correctness issue to raise.

• Correctness and portability: the exact-width 4/8/16-byte big-endian loads are equivalent to the prior signed Int256 decoder, while shorter widths retain explicit sign extension. Target-precision validation still precedes every narrowing cast, including the asymmetric signed minimum and whole-source-domain shortcut.
• Lifecycle and compatibility: plain, dictionary, sparse selected-range, BYTE_STREAM_SPLIT, raw-predicate, permissive-null, strict-error, and rollback paths preserve their existing output coordinates and failure semantics. Rescaling, variable BYTE_ARRAY values, and fixed widths above 16 bytes remain on the unchanged Int256 path.
• Tests: the added cases cover the 4-byte target-precision boundaries, permissive null marking, strict rollback over a pre-existing row, shorter negative sign extension, and the complete int32 source domain. Exact 8/16-byte and stateful integration cases are not newly added, but tracing their shared decoder/materialization contracts did not reveal a distinct coverage-driven defect. Per the runner's static-only instruction, I did not rerun builds or tests.
• Performance: the fast path removes per-row Int256 work only for same-scale fixed binary inputs where the narrower carrier is proven safe; the scale-changing and wider fallbacks are unchanged. The reported benchmark was not independently reproduced in this review.
• User focus: no additional focus was provided, so I reviewed the whole PR without narrowing scope.
• Review completion: the main risk scan, two full-coverage reviews, and a separate risk-focused adversarial review all converged on NO_NEW_VALUABLE_FINDINGS; there were no existing inline threads, proposed inline comments, or unresolved candidates. No repository-local code-review skill or required AGENTS.md file was present in the review checkout.

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 100.00% (61/61) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	75.26% (30796/40917)
Line Coverage	59.56% (341160/572837)
Region Coverage	56.90% (287012/504449)
Branch Coverage	58.28% (128675/220792)