[fix](function) Round Decimal values with zero decimal places

[Mryange]

format_round skipped rounding for Decimal values when decimal_places was zero because the rounding branch required a positive decimal-place count. Values such as 1.9 and -1.9 therefore produced truncated results instead of 2 and -2. The condition now performs rounding whenever the input scale exceeds the requested decimal places, including zero, and regression coverage verifies positive, negative, and table-column Decimal values.

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

[Mryange]

/review

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

[github-actions]

Static review opinion: LGTM; no PR-introduced blocking issue found.

Critical checkpoint conclusions:

• Goal and correctness: the changed predicate now runs the existing Decimal fractional reduction when zero places are requested. For DecimalV2/32/64/128, the zero-place quotient is one digit, half-away-from-zero behavior is preserved, sign/carry handling is correct, and the carry plus output buffer remain in range.
• Scope and parallel paths: this is a focused one-condition fix. Double and integer behavior is unchanged, and all implemented Decimal widths share the corrected helper. The registered Decimal256 executor gap was independently verified as real but pre-existing at the base SHA for every place count; Decimal256 never reaches the changed helper, so it is not a finding against this PR.
• Tests: the changed expected results are correct and cover positive/negative Decimal32 carry/no-carry plus a Decimal128 column path. Exact-half, sub-unit, DecimalV2/64, all-9s, and row-varying-place cases would strengthen coverage, but static tracing found no defect in those paths. Per the review contract, no build or test was run here, so the regression result is not independently executed.
• Concurrency, lifecycle, compatibility, and operations: no shared state, locking, ownership, configuration, FE-BE protocol, persistence, storage format, transaction, observability, or ABI behavior changes. Existing null and Status propagation remain intact.
• Performance: the added constant-time exponent lookup and division occur only where required for correct zero-place Decimal rounding; no material allocation or asymptotic regression was found.
• User focus: no additional focus was supplied.

Review completion: the main risk scan and two normal/risk convergence rounds completed; both Round 2 reviewers returned NO_NEW_VALUABLE_FINDINGS, every candidate was adjudicated, the final duplicate fence is empty, and the live PR head was verified at 1c2a288 before submission.