feat(collector): advertise and execute window implementation capabilities

[zzylol]

Goal

Give ASAPQuery-backend an authoritative, versioned capability contract for concrete window implementations, and make ASAPCollector validate and execute the physical plan it advertises.

ASAPPlanner selects abstract window frameworks such as tumbling, sliding, or exponential histogram together with summary and lifecycle candidates. ASAPQuery-backend selects a supported concrete library/configuration for the chosen framework. ASAPCollector executes that compiled CollectorPlan and reports runtime evidence; it does not re-plan either abstraction.

Current compatibility baseline

At the referenced implementation revision, CollectorPlan validation effectively supports continuously maintained incremental summary state, tumbling windows with window size equal to slide, and full-state transmission for a limited algorithm set. Sliding, exponential-histogram, other lifecycle modes, and other transmission modes must not be advertised until their execution paths are implemented and tested.

Required behavior

• Publish typed capabilities for supported summary algorithms and parameters, concrete window implementations, window-size and slide bounds, pane composition, retention, watermark/lateness behavior, lifecycle and maintenance modes, transmission modes, resource limits, and plan schema versions.
• Let ASAPQuery-backend use those capabilities to determine which concrete realizations can provide evidence for each Planner-selected abstract framework.
• Reject a CollectorPlan when its algorithm, parameters, physical window configuration, lifecycle mode, transmission, or resource requirements are unsupported. Never silently coerce a window to tumbling or set slide equal to size.
• Preserve the backend-issued stable materialization identity in status and data-plane output.
• Add execution support incrementally for sliding/pane and PromSketch exponential-histogram realizations; advertise each only after its ingest, retention, readout, restart, and update path works.
• Return structured rejection reasons so the control plane can remove an infeasible realization and recompile.
• Apply plan publication atomically: partial or stale generations must not become active.
• Keep cost-based choice out of Collector. Runtime measurements may be reported as evidence for Planner/backend optimization.

Acceptance tests

• Capability negotiation represents the current tumbling-only baseline exactly.
• Unsupported sliding or EH physical plans are rejected before activation with a typed reason.
• For every advertised implementation, window boundaries, late data, retention expiry, restart recovery, and query readout match the compiled semantics.
• CollectorPlan and emitted summary metadata retain the same generation and materialization identity.
• Unknown variants and schema versions fail closed.
• End-to-end tests cover Planner abstract choice through backend compilation, Collector apply/status, and query readout for each enabled framework.

References

• feat(cost): model streaming summary resources ASAPPlanner#331
• docs: clarify Planner window ownership #586