branch-4.1: [chore](paimon) Upgrade Paimon to 1.4.2

[suxiaogang223]

What changes

• Upgrade the FE Paimon dependency from 1.3.1 to 1.4.2.
• Update the Paimon test IO manager implementation for the new pickTempDir() API.

Why

Use the latest stable Paimon release and keep the Doris Paimon connector compatible with its updated IO manager interface.

Validation

• DISABLE_BUILD_UI=ON ./build.sh --fe
• FE Maven reactor completed successfully with BUILD SUCCESS.
• UI compilation was skipped.
• The build reused the main checkout's thirdparty/installed.

[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?

[suxiaogang223]

run buildall

[Gabriel39]

run buildall

[Gabriel39]

I found one planning-path performance regression in the Paimon 1.4 API adaptation. Please keep the merged-row-count computation guarded by COUNT(*) pushdown and add regression coverage for non-count scans.

[Gabriel39]

mergedRowCount() is now evaluated for every DataSplit, even when applyCountPushdown is false. In Paimon 1.4.2 this method can call dataEvolutionMergedRowCount(), which builds and sorts file ranges, so ordinary Paimon scans gain avoidable planning work; previously the applyCountPushdown && ... short-circuit skipped it entirely. Please keep this call behind the pushdown guard (for example, use applyCountPushdown ? dataSplit.mergedRowCount() : OptionalLong.empty()) and add a regression test verifying that a non-count scan does not invoke mergedRowCount().

[hello-stephen]

FE UT Coverage Report

Increment line coverage 87.50% (7/8) 🎉
Increment coverage report
Complete coverage report

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 0.00% (0/8) 🎉
Increment coverage report
Complete coverage report