CountMinSketch (no heap) ignores aggregation_sub_type sum/count distinction, always uses SUM semantics

[milindsrivastava1997]

Problem

The planner emits aggregationSubType: "sum" or "count" for AggregationType::CountMinSketch configs specifically to distinguish weighting semantics:

// asap-planner-rs/src/optimizer/candidate_gen.rs
fn derive_sub_type(stat: Statistic, agg_type: AggregationType) -> String {
    match (stat, agg_type) {
        ...
        (Statistic::Sum, AggregationType::CountMinSketch) => "sum",
        (Statistic::Count, AggregationType::CountMinSketch) => "count",
        _ => "",
    }
    .to_string()
}

But the query engine never reads aggregation_sub_type for this path:

• create_accumulator_updater() (asap-query-engine/src/precompute_engine/accumulator_factory.rs) routes AggregationType::CountMinSketch straight to cms_params(config) and builds a CmsAccumulatorUpdater — sub_type is only consulted for SingleSubpopulation/MultipleSubpopulation.
• CmsAccumulatorUpdater::update_keyed always feeds value (the resolved sample value) as the sketch weight — there is no count_events-style flag like CmsWithHeapAccumulatorUpdater has.
• CountMinSketchAccumulator::query() ignores the _statistic argument entirely and just returns the raw estimate.

Net effect: a COUNT(column) query planned onto plain CountMinSketch (no heap) will sum the resolved sample values into the sketch instead of counting events (weight 1 per observation), silently returning SUM semantics for a COUNT query.

The heap variant (CountMinSketchWithHeap, used for top-k) already solved an equivalent problem via a count_events parameter (added in #389) — cms_count_events() reads parameters.count_events, defaulting to true. Plain CountMinSketch never got the equivalent treatment; the aggregation_sub_type the planner emits for it is currently dead on the engine side.

Found while reviewing PR #483.

[milindsrivastava1997]

Proposed approach: Remove sub_type and add a dummy field with value = 1, to differentiate between count and sum.
See context here - #483 (comment)