sql: Incorrect aggregation result for variance-equivalent expression on constant input (returns -1/n instead of 0)

**Describe the problem**

Please describe the issue you observed, and any steps we can take to reproduce it:

A query that is mathematically equivalent to VAR_POP over a constant input returns an incorrect non-zero result.

For any constant value c, the following expression:
(SUM(c * c) - (SUM(c) * SUM(c)) / COUNT(c)) / COUNT(c)

is mathematically guaranteed to evaluate to 0, regardless of the data distribution or join structure.

However, CockroachDB consistently returns a deterministic non-zero value:
-0.090909090909090909091 (i.e., -1/11)

This result is incorrect and indicates a violation of aggregation equivalence. The issue appears to be independent of the constant value used and depends only on the query structure.

The observed result suggests that aggregation functions (SUM, COUNT) are evaluated at inconsistent levels (e.g., different join cardinalities or partial aggregation scopes), leading to incorrect computation.

**To Reproduce**
1. Set up a CockroachDB cluster (single-node is sufficient)
2. Execute the following SQL:
create table t0
(
c0 timestamp
);

create table t1
(
c0 bigint
unique
);

create table t2
(
c0 bit(189) not null
);

-- t0
INSERT INTO public.t0 (c0) VALUES
('1969-12-08 19:18:57.000000'),
('1970-01-09 09:36:22.000000'),
('1970-01-20 09:32:22.000000'),
('1970-01-11 00:06:06.000000');

-- t1
INSERT INTO public.t1 (c0) VALUES
(424210762),
(NULL),
(-766426769);

-- t2
INSERT INTO public.t2 (c0) VALUES
('101001001011011000100001011010001010010110111110111111000010010111111111001001111100000000110101010110111011010001001111010110101101110001010100001110100100101011000011100100000101001101110'),
('001101101001101111101110000111100000111010001110111101101111100111101011111010001111000010011100100110000100011110001001111011011000010001100011101111010111000111010010110000001100100111010'),
('111111111011111010010010100000111101111110001111101101010101011110100101110010001110100001001001001011111100001000111110000101001110100000011100010100011000011010101010100000110011010011100'),
('101101010011001110000010100110111001010101100001001100100000011011100001000001011011001100011000101110000111001010011110000110000101000101100000101000100100011000010111000011001000000010010'),
('111010000001001011111101111111110001011010011101000011010000111110001001111101100000100011111101100100001001011101100100100010111011011101001000111000100111001110111011111001001111100101010'),
('110000110001111001111011001110100010111100101101000000010100111000000000001101100100001010111010010111010011010000110010101001011000011000000111001111100010100101101100001000010011101010110'),
('010000001011110101100000010010101100110101000110101011101010010110010111111110001011000001101010000110111010001101100010000100111010000010100000011111000011111000100011111101100000100100001'),
('100100011111110010010101111100001101010001101110010000100110010100100100001000011001000100010010100110001000101001001001011110110000100000010100101101010011010111111001111000010011000010001'),
('010111111010000100101001100111111001011000111010111101111011110010001001010000010110011001011000011011111010000100011001110000011011111111101000000100011010110010111101110110110010110101011'),
('110111001101110110110100000111001000000101111001100010010000011001100001111010100010011000010110000001010010110111000100111010010111100010100011110111001010010010110111101111101111100110110'),
('111010001011011011001010101001101100011011101111111000000101111000010111101000111100000110101010010111100101101100101011101100101001100111011101001110110110100101000111110011111011011000111');

SELECT (SUM(((-1737664727)) * ((-1737664727))) - (SUM((-1737664727)) * SUM((-1737664727))) / COUNT((-1737664727))) /
COUNT((-1737664727)),
(SUM(((2030393942)) * ((2030393942))) - (SUM((2030393942)) * SUM((2030393942))) / COUNT((2030393942))) /
COUNT((2030393942))
FROM t1,
t0,
t2
GROUP BY t1.c0;

3. Observe the query result

**Expected behavior**
The result should be:
0
Because for constant input:
VAR_POP(c) = 0
and the tested expression is algebraically equivalent to VAR_POP.

**Actual behavior**
The query returns:
-0.090909090909090909091
which equals:
-1 / 11
This is incorrect and violates basic mathematical properties of variance.

**Additional data / screenshots**
Key observations:
• The incorrect result is deterministic and reproducible
• The result depends on the cardinality of one table (t2, size = 11)
• Changing the constant value (positive/negative) does not affect the result
• Indicates aggregation is being computed at inconsistent levels (e.g., partial aggregation, pushdown, or constant folding issue)

**Environment:**
• CockroachDB version:v13.0.0
• Server OS: macOS
• Client: cockroach sql / DataGrip

**Additional context**
This is a silent wrong-result bug in aggregation, which is particularly critical:
• It violates algebraic equivalence of aggregate expressions
• It may affect statistical computations (variance, stddev)
• No warning or error is reported
• Results appear valid but are incorrect

This type of issue can lead to incorrect analytical results in production workloads.

Jira issue: CRDB-62925