Exact Sum over an Int64 column is priced by Stage 3 but does not bind in the executor

[zzylol]

Problem

Stage 3 prices a plan that the executor cannot bind. In #509 Example 2's integer Q3:

SELECT SQRT(SUM(c * c)) FROM (SELECT src_ip, COUNT(*) AS c FROM flows GROUP BY src_ip)

c * c is Int64, and Pass 1 offers an exact Sum summary over it. plan_stages (with the executor's capabilities, executor_models()) prices that candidate as valid. Binding it in the executor fails with:

summary update type is unsupported by its family

The exact summary build only accepts Float64 update columns (UnivMon also takes Utf8, Int64 and Bool): crates/executor/src/operators/summary/mod.rs:147-155 on stack/fix-sql-count-sketches. So a cost-model change could select a plan that cannot run. This is the same class of bug as the SQL COUNT(*) per-group sketches fixed in #620.

Repro

On stack/fix-sql-count-sketches (#620), take priced_example2_candidates_bind in crates/integration-tests/tests/pass1_sql_coverage.rs. Swap its Q3 from the CAST(c AS DOUBLE) form back to EXAMPLE2[2] (the integer c * c), then run:

cargo test -p asap-integration-tests --test pass1_sql_coverage priced_example2_candidates_bind

The test then fails on the exact-Sum candidate. Today it uses the floating Q3 (Q3_FLOAT in planner_layering_example2.rs) to stay green.

Fix options

• Executor (recommended): the exact Sum (and other exact numeric aggregates) accepts Int64 updates, accumulating in i64 or in f64 to match the planner's declared output type. This makes the plan runnable rather than hiding it.
• Stage 3 guard: the capability check rejects summary builds whose update column type the deployment can't consume. That needs the capability set to describe update types.

Whichever is chosen, priced_example2_candidates_bind should go back to the design's integer Q3.

Found by the "every priced candidate binds" invariant added in #620.