feat: support corr with a general bivariate aggregate type

[zzylol]

Why

Closes #414. DataFusion recognizes corr, but ASAPPlanner rejects it because its built-in value reducers carry only one input column.

What

Add the general AggIntent::Bivariate { op, left, right } shape, with BivariateAggOp::Correlation as its first operation. SQL correlation accepts expressions in either argument and returns nullable Float64.

How

Resolve both inputs to column IDs and expose them through input_cols() for dependency and operand-state checks. Project both SQL arguments to preserve casts and qualified join columns. Keep correlation exact, exclude it from scalar rollups/sketch selection, and allow physical hash-aggregate costing with provider-supplied state size.

Before this PR

SELECT corr(x, y * 2) AS r FROM a fails with unsupported aggregate: corr.

After this PR

The query lowers to a projection feeding Bivariate { op: Correlation, left: 0, right: 1 }, with a nullable numeric output. Future paired aggregates can add an operation without adding another argument-carrying IR variant.

Evidence

The regression test first reproduced unsupported aggregate: corr, then passed after implementation. SQL tests also preserve distinct inputs for corr(a.x, b.x) across a join and compile the retained exact query to an executable DAG. Screenshots and performance measurements: not applicable.

Verification

• cargo +1.98.0 test --workspace --locked: 1,141 passed, no failures or ignored tests.
• cargo +1.98.0 clippy --workspace --all-targets --all-features --locked -- -D warnings: passed.
• cargo +1.98.0 fmt --all -- --check and git diff --check: passed.
• Tests and Clippy used an isolated target directory with dev/test debug info disabled; runtime numerical evaluation was not exercised.

New coverage:

• corr_result_is_nullable_float: reproduces the original error and checks output name/type/nullability.
• corr_materializes_both_arguments: retains expressions, casts, and constants in either input.
• corr_preserves_qualified_join_inputs: binds same-named columns to different join sides.
• corr_coexists_with_grouping_having_and_other_measures: retains both arguments alongside grouping, HAVING, sorting, and another reducer.
• corr_repeated_input_and_serialization: preserves repeated argument positions and round-trips the query.
• corr_rejects_unrepresented_forms: rejects modifiers, window usage, and invalid arity.
• corr_survives_exact_plan_compilation: preserves the bivariate intent through exact fallback and DAG compilation.
• Core tests cover serialization/exactness, both usage-derived dependencies, qualified resolution/missing inputs, both operand-state checks, exclusion from sketch selection, and physical hash-aggregate costing.

Architectural decisions

Use a typed bivariate aggregate plus an operation enum, rather than a correlation-specific argument shape or opaque extension JSON. This makes both dependencies available to core binding and lets later operations reuse the representation. Preserve existing single-input APIs; dependency walkers use input_cols().

Post-ASAP mapping and current scope

The current mapping is an exact fallback:

AggIntent::Bivariate { op: Correlation, left, right }
    -> Implementation::PassThrough
    -> SummaryExpr::KeepPreAsap

PassThrough preserves the original aggregate for exact execution by the engine; it does not skip correlation. This PR tracks both input dependencies, checks both operand states, permits physical HashAggregate costing with provider-supplied state size, and excludes correlation from single-column sketches and scalar-result rollups.

There is no dedicated correlation summary implementation yet. The following remain unimplemented:

• A maintained, updatable, mergeable correlation accumulator.
• A correlation readout from that accumulator.
• Query-time composition via ExactOperation::Aggregate over independently realized child plans; correlation is not enabled in that reducer path.

The executable-DAG test covers the retained KeepPreAsap fallback. It does not demonstrate a maintained correlation state or a dedicated post-ASAP correlation execution operator.

Limitations and follow-up

Only correlation is implemented initially. DISTINCT, aggregate FILTER/ORDER BY, explicit null treatment, and OVER remain unsupported. No maintained correlation accumulator or approximation is added. Numerical execution and pairwise null handling remain the executing engine's responsibility; this PR validates planning, not runtime numerical results.

Human review — do not complete with an agent

• The MVP boundary is correct.
• New conceptual layers or public interfaces are necessary.
• The before/after description matches the intended product behavior.
• Human reviewer:
• Decision and rationale:

[Selvomega]

As described in the comment. I might directly use AggIntent::PearsonCorr
if you still think current design good, you can just merge it

[zzylol]

As described in the comment. I might directly use AggIntent::PearsonCorr if you still think current design good, you can just merge it

I agree using AggIntent::PearsonCorr is better. Would you like to take the change?