Resolve correlated aggregates at their outer scope

[fulghum]

Correlated aggregates referenced only inside HAVING subqueries could be registered in the inner query scope. This fed an already-aggregated INT64 result back into an INT32 aggregate buffer and produced a runtime type error.

Pre-register aggregates on their owning outer grouping scope, including aggregates nested beneath scalar functions and valid unqualified references in no-FROM subqueries. Preserve local alias shadowing, mixed local/outer arguments, and independent inner aggregates.

Additional passing and skipped coverage documents adjacent nested semantic-scope behavior. The broader semantic resolver work is tracked by #3814.

Reported by the Doltgres regression comparison: dolthub/doltgresql#3273 (comment)

[itoqa]

Commit: db4d82f: 14 test cases ran, 14 passed ✅.

Summary

Coverage spans grouped and nested data calculations, including correlated values, joins, local-name shadowing, null handling, row counts, large numeric totals, and mixed inner/outer inputs. It includes normal business-logic paths, boundary and edge cases, plus an adversarial check of unsupported array-star behavior, with all exercised behaviors reported healthy.

Safe to merge — the exercised query and aggregation behaviors show no regressions or PR-attributable failures, and the unsupported array-star observation is expected behavior rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Aggregate	The grouped query finished successfully and returned only group 2 with a distinct sum of 1.
✅	—	Aggregate	The inner SUM uses its own table rows and returns both expected groups. The outer grouping stays unchanged.
✅	—	Aggregate	The joined inner query returned group 2 as expected. The outer total stayed linked to the right group, with no runtime or type errors.
✅	—	General	Grouped database queries keep the right values when an aggregate uses only an outer group or mixes outer and inner columns. Both boundary cases return the expected rows without errors.
✅	—	General	The grouped query returned all three expected rows. The joined values stayed together, with no cross-group leakage or execution error.
✅	—	General	The grouped queries returned the expected rows and values without planner or runtime errors.
✅	—	General	The grouped queries returned the expected rows. An unqualified name with no local table used the outer grouped value, while the same name in a local table stayed local.
✅	—	Coalesce	The grouped query returned only group 2 when the outer aggregate was wrapped in COALESCE. It completed without an aggregate type or runtime error.
✅	—	Coalesce	The grouped query returned group 2 as expected. The nested query correctly used the value from the outer group.
✅	—	Count	COUNT(*) was built and evaluated successfully. The query returned 5 rows for the single-group case and the expected count for each grouped result.
✅	—	Count	Verified acceptable by independent adversarial review: the reported expectation does not match what the code actually promises. Review notes: The query is reachable and the planner does reject its star argument, but rejection is consistent with the repository's documented and tested distinction: JSON_ARRAY constructs an array from scalar arguments, whereas JSON_ARRAYAGG performs grouped row collection. The isolated, untested jsonarray star branch is dead under the canonical json_array name and builds a JSON_ARRAYAGG node internally; it …
✅	—	Rev	The grouped query returns one matching group and keeps the full sum of 2147483648 without a runtime or conversion error.
✅	—	Shadowing	The grouped query returned both expected groups when the inner table used the same column name as the outer query. The inner alias stayed local, so the query produced the correct results without an execution error.
✅	—	Shadowing	The mixed aggregate completed successfully and returned all three expected grouped rows: (1), (1), and (2). The outer value and inner value stayed available to the same calculation.

Tip

Reply with @itoqa to send us feedback on this test run.