feat(core): interface types for L1 input, L3 intent algebra, L4 sketch algebra

[milindsrivastava1997]

Summary

• Adds Cargo workspace skeleton (Cargo.toml at root, crates/core/)
• Defines L1 input boundary: QueryWorkload, QueryLanguage (with SqlDialect variants), BatchEntry, RepeatingEntry, DataCharacteristics, DataDistribution, QueryRequirements
• Defines L3 output boundary (intent_algebra): QueryExpr DAG with Rc<L3Node> children, L3Schema/L3DataType/L3Field, HasSchema trait, AggIntent, Source, TimeWindowKind (renamed from WindowKind)
• Defines L4 output boundary (sketch_algebra): SummaryExpr DAG with Rc<L4Node> children, L4Schema/L4DataType (Primitive(L3DataType) | Sketch(SketchKind, SketchParams)), SketchKind, SketchParams, SketchQuery
• Shared AccuracyTarget enum (Epsilon / EpsilonDelta / Exact) in types.rs

Design choices

• Node wraps schema: L3Node { expr: QueryExpr, schema: L3Schema } and L4Node { expr: SummaryExpr, schema: L4Schema } — every Rc<*Node> pointer IS an edge, carrying the child's output schema inline. No separate Edge type.
• L3/L4 schemas are separate types: L4DataType::Primitive(L3DataType) wraps L3 types; L4DataType::Sketch(...) is L4-only. L3 nodes structurally cannot carry sketch-typed columns.
• No logic: all methods on AggIntent and HasSchema are todo!() stubs. Zero external dependencies.

Test plan

• cargo check passes with zero warnings

🤖 Generated with Claude Code

[milindsrivastava1997]

Exact accumulators need to be representable in SketchKind

In ASAP, not all precomputed aggregations are approximate. Sum, Count, Min/Max, Increase, and Rate are stored and merged in the sketch store with exact semantics — they map to AggregationType::{Sum, MinMax, Increase, ...} in the current asap-query-engine.

If these stay as Logical(Aggregate) nodes in L4, ASAPController can't emit SummaryRead for them, and asap-query-engine would fall through to a DataFusion execution path that expects raw data rather than precomputed accumulators.

Proposed fix: extend SketchKind with exact-accumulator variants:

pub enum SketchKind {
    // Exact accumulators (no approximation error)
    Sum,
    Count,
    MinMax,
    Increase,
    Rate,
    // Approximate sketches (existing)
    Kll,
    Cms,
    Hll,
    DDSketch,
    CmsWithHeap,
    Kmv,
    Theta,
}

This keeps the L4 representation uniform — all precomputed aggregations (exact or approximate) flow through the same SummaryRead → SummaryMerge → SummaryEstimate pipeline. The naming is a slight misnomer for the exact variants, but the alternative (a parallel AccumulatorKind + SummaryAccumulate node) doubles the node types and translation logic downstream with no real benefit at this stage.

Also needed in the same PR: a SummaryRead node added to SummaryExpr (distinct from SummaryAgg). SummaryAgg implies computing a sketch from raw data; SummaryRead means fetching a precomputed sketch from the ASAP store. Proposed shape:

SummaryRead {
    metric: MetricRef,
    sketch: SketchKind,
    params: SketchParams,
    by: Vec<GroupKey>,
    time_window: TimeWindowKind,
    time_range: TimeRange,   // relative Duration for repeating queries, absolute for batch
    spatial_filter: Option<LabelFilter>,
}

[milindsrivastava1997]

One clarification on SummaryRead: it doesn't strictly need to live in asap-control-core. Since SummaryRead is specific to ASAP's precomputed-sketch-store model (reading a stored aggregation by agg_id, time range, and sketch type), it can be defined in a downstream artifact — either asap-query-engine itself or a shared ASAP-specific crate (e.g. ASAPCollector / asap-common). That keeps asap-control-core's L4 IR general-purpose and free of storage-model assumptions. The asap-control-core PR only needs the SketchKind extension (D5 above); SummaryRead is a downstream concern.