sql: preserve integer digits in decimal division

[Alignyx]

Fixes #168373.

Root cause

SQL decimal division always used the fixed 20-significant-digit DecimalCtx. In the reported expression, 5845710769898530048144 / 44 requires 21 integer digits, so the exact quotient 132857062952239319276 was rounded to 1.3285706295223931928E+20. Subtracting that rounded quotient from the exact sum left -4, and the final division produced -1/11 even though every input in the group was constant and the variance-equivalent expression must be zero.

How I tracked it down

I reproduced the result for both constants and all three reported groups, then compared the expression with VAR_POP, a translation to zero, and an algebraically equivalent form that performs the division last; all three metamorphic oracles returned zero. Changing only the row count showed the precision boundary: counts 4 and 11 returned zero, while 44 and 101 returned -1/n. Optimizer and distributed plans had the same aggregation levels, and row and vectorized execution failed identically. Inspecting the final scalar render then exposed the rounded quotient and exact -4 residual, locating the problem in the shared decimal division policy rather than aggregation.

Fix

Added tree.DecimalQuo, which first divides with the existing 20-digit context and retries only when an inexact finite result has a positive exponent, adding just enough precision to retain the quotient's integer portion. The helper preserves aliased operands across a retry. Row evaluation, numeric constant resolution, and generated vectorized decimal/integer division now use the same helper. Ordinary fractional results retain the established 20-significant-digit behavior, so this does not raise the global decimal context or change unrelated decimal operations.

Test coverage

• Added evaluator coverage for the exact large quotient that triggered the bug and for 10/3 retaining the existing 20-digit result.
• Added the reported aggregate expression for both large constants and all three groups, with VAR_POP as the zero oracle.
• Verified the regression across five local/fake-distributed row, vectorized, and disk-spilling configurations; ran the full evaluator, tree, and vectorized projection tests and the complete aggregate and decimal logic suites; and confirmed the generated vectorized output is reproducible.

[blathers-crl]

Thank you for contributing to CockroachDB. Please ensure you have followed the guidelines for creating a PR.

My owl senses detect your PR is good for review. Please keep an eye out for any test failures in CI.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}