feat(planner): add basic scaffolding for optimization problem in planner

[milindsrivastava1997]

• feat(optimizer): scaffold OptimizerSolution type and translator
• feat(optimizer): add AQE extractor with GCD/min/sum frequency tracking
• feat(optimizer): wire all-EXACT end-to-end pipeline (Phase 1)

[milindsrivastava1997]

Code review findings (ranked, verified against source)

Correctness — all confirmed by reading the actual code:

1. aqe_extractor.rs:83 — entry.2 += 1.0 / rqe.t_repeat_secs as f64 with no zero-check. t_repeat_secs comes straight from QueryGroup.repetition_delay: u64 (config/input.rs:51) with zero validation anywhere in the load path. A config with repetition_delay: 0 silently produces +inf query frequency that poisons cost comparisons for that AQE.
2. aqe_extractor.rs:85-89 — the GCD accumulator uses entry.4 == 0 as both "uninitialized" and a legitimate value. A zero t_repeat_secs merging into a bucket causes later values to overwrite instead of GCD-combine, corrupting t_repeat_gcd_secs for that whole AQE.
3. promql_utilities/src/query_logics/parsing.rs:71,81,84 (called from aqe_extractor.rs extract_requirements) — get_statistics_to_compute panic!s on any matched-but-unrecognized statistic/function name, contradicting aqe_extractor.rs:64-65's doc comment that unsupported queries are "skipped with a warning." Any dashboard query matching a pattern but using a statistic outside the current enum crashes the whole optimizer_cli run instead of skipping that one leaf.
4. greedy.rs:38-40 — min_by comparator does .partial_cmp(...).unwrap(). optimizer_cli's --rho is parsed as a bare f64 with no validation; --rho nan propagates NaN through every cost, making partial_cmp return None and panicking instead of failing cleanly.
5. translator.rs:60 vs candidate_gen.rs — retention_count_for_assignment hardcodes 1 for QueryMethod::Subtract, while candidate_gen.rs sets the deployed config's actual retained-window count to n_windows. Self-documented as a Phase-3 placeholder, but worth flagging now since it's a silent mismatch waiting to bite once wired up.

Reuse/cleanup (lower severity, all confirmed):

6. aqe_extractor.rs:250 (decompose_to_leaves/arm_to_query_string/strip_parens) — duplicates SingleQueryProcessor::get_binary_arm_queries/strip_parens already in planner/promql.rs:31-145. Two copies of PromQL binary-arm decomposition will drift.
7. aqe_extractor.rs:298 (extract_requirements) — duplicates SimplePromQLEngine::build_query_requirements_promql (query-engine crate); the author's own TODO comment already flags this.
8. greedy.rs:35-46 — total_cost_rate is recomputed twice per min_by comparison, then a 3rd/4th time afterward to recover the cost breakdown for best. Cheap fix: map once into (candidate, cost) pairs, min_by_key, reuse.
9. pipeline.rs — run_all_exact_pipeline and run_greedy_pipeline are near-identical shells differing only in the solving step; a Phase-3 MIP pipeline will likely triple this boilerplate. Consider one run_pipeline(config, solver) now.

Skipped as non-findings: the derive_sub_type empty-string case (inert under current required_sub_type contract), param_grid's bool-slice plumbing, and the num_sketch_served/num_exact_fallback redundant getters — all real but cosmetic, not worth the budget here. No CLAUDE.md exists in this repo, so no conventions violations to report.

Findings from manual code review (we need to prioritize these)

Some of these may be big enough that we need to solve them in different issues after merging this. Some of these may be big enough to warrant an entire session/discussion.

solution.rs:

• can we change sec to millisec (in other files too)
• can we rename QueryMethod::Neither? it sounds weird
• do we/can we eforce num_windows > 1 for QueryMethod::Merge
• what is f_a?
• Can we capitalize AQE and RQE structs?
• why doesnt optimizersolution have estimate query cost per second

sketch_properties.rs:

• what are SingleSubpopulation and MultipleSubpopulation types?
• Should we up-level sketch properties as traits? Should they live in asap_sketchlib?

candidate_gen.rs:

• we should put constants in a separate file
• what should we do for multiple statistics? What happens right now? If unsupported, create an issue for this
• CMSWithHeap -- we should remove count_events from the parameters, and instead have it as a subtype. That's what "sum" vs "count" does for CountMinSketch
• What are the semantics of the "range_a_secs" parameter? Is this from a PromQL range query (where a query itself is repeated multipole times) or is it the time range of data queries by a single query instance? The "spatial query has None range" comment makes me question this. I guess technically, spatial query should have range = scrape interval? It's quite possible this is an issue with code outside this PR. Nonetheless, we should investigate and log issues as necessary
• For sliding windows, grid search, the size of sliding window can also change right? If/when we do this, this may also need changes to the determine_query_method function
• Here is my high-level logic for window param searching. I am curious to know if the code implements this or something different:
  • For tumbling, we need window size as multiples of scrape interval, and window size <= t_repeat
  • For sliding, we need both size and slide as multiple of scrape interval. window size <= time range of query. window slize <= t_repeat

aqe_extractor.rs:

• can we replace the gcd function with a library call?

translator.rs:

• for number of aggregates to retain for QueryMethod::Subtract, 1 makes sense but we also need to retain another aggregate that represents the sketch used for the previous query instance. It's possible this calculation/parameter is being used in 2 places and must be dismbiguated into 2 different parameters

cost_model.rs:

• up level constants to a different file
• can we rename: rho_g, n, g, a, f_a, etc
• what is n? what is N(s, g)? We need more descriptive names
• mem_retain for tumbling windows -- is this being double counted because it is also included in the query_memory?