Window implementation candidates: sources, rewrites, and simplification questions #705

Context

A query's WindowImplementationCandidate list (PlanningQuery.window_implementations) is built from several sources and then rewritten in several places. This issue records how that works today and lists open questions, with the goal of simplifying the interface.

Where candidates come from

S3 today, for each range-selector window W (or the lookback if the query has none), with evaluation interval E:

• E < W && W % E == 0: Sliding, slide = E, two candidates: Pane{E} and FullWindow
• otherwise: Tumbling, slide = W, one candidate: Pane{W}
• Cost: derived_window_cost scales the snapshot's single implementation_cost template.

Rewrites and filters

Consumption: validate_window_implementations → ControlPlaneCostModel::with_window_implementation_costs → select_lifecycle → Planner plan_summary_maintenance_lifecycles → selected_window_implementation_id.

Questions

1. Can S1 be deleted? No production caller sets implementation.window_candidates, and no checked-in snapshot does either. Its only users are tests: compiler.rs (supplied_window_candidates_are_not_replaced_by_the_derivation, ~:5482), and data_plane/tests/asapquery_compatibility_process_e2e.rs:789 (run_shared_dashboard(multi_pane=true)), which injects a 5s pane with a hand-set cost to force the choice. Deleting it removes window_candidates, the key check at :547, the contains_key branches at :621/:673/:741, and makes synthesized_window_queries always cover every query. What should replace provider-priced pane quotes in those tests? Should the backend keep a way to accept measured per-pane costs, or is the derived formula the intended source of truth?
2. Should S2 derive candidates too? The HTTP path is the only entry for DistributedCollectors (the snapshot path requires BackendLocalRemoteWrite). Its only in-repo caller is data_plane/tests/backend_process_e2e.rs. Should it keep caller-supplied candidates, or share S3?
3. Intermediate pane sizes. Proposal: also offer pane p with E < p < W, p % E == 0, W % p == 0. But WindowMaterializationLayout::validate (crates/asap_types/src/aggregation_config.rs:50) requires the pane to divide both window and slide. With slide = E, a flat Pane{p} with p > E is rejected, and readouts at every E tick could not align with pane ends anyway. Options:
   • a) HierarchicalRollup { base_pane_secs: E, levels_secs: [p] }. The compiler accepts it only as Extension("backend.exact-hierarchical-rollup.v1") (compiler.rs:2561), and the data plane has no implementation today.
   • b) Finer panes p | gcd(E, W), p < E. These never beat Pane{E} for one query, but could enable sharing across queries with different E.
   • c) Change the slide to p. That changes evaluation alignment, so off-tick evaluations fall back to exact.
     Which is intended?
4. Tumbling fallback when W % E != 0 or E > W. Example: W = 300s, E = 45s produces Tumbling Pane{300}, slide 300. Evaluations every 45s rarely line up with pane ends, so most reads should fail the serving pane-alignment check and go to exact. Should S3 use Pane{gcd(E, W)} with slide gcd(E, W) instead?
5. R1 / R3 only apply to S3 queries. If S1 goes away, is the "synthesized" distinction still needed at all?