MILP planner writes a roll-up plan at the first RAQE's grouping #813

Problem. asap-planner-rs/src/optimizer/milp_output.rs aggregation_config takes a deployment's labels from the first RAQE it serves (items.first().requirements), on the assumption that every RAQE on a deployment shares its grouping.

ProjectASAP/sketch-bench#190 lets the rqe-optimizer serve a RAQE grouped by G_r from a deployment grouped by a superset G_d (a roll-up): KLL, DDSketch, HLL and exact sum/min/max can merge fine groups into coarse ones at query time. Once that lands, the MILP planner can be handed a plan where one deployment serves sum by (job) and sum by (job, instance).

milp_output would then write one aggregation at whichever grouping the first RAQE has:

• If the first is the coarse one, the engine precomputes per job, and the per-(job, instance) query gets no correct answer.
• If the first is the fine one, the coarse query is answered from a deployment the engine can't roll up yet.

Nothing errors. asap-planner-rs tracks sketch-bench branch = "main", so the next lockfile update picks this up.

Fix. Until the engine can read a deployment at a coarser grouping, plan_to_planner_output refuses any RAQE whose grouping differs from its deployment's (MilpOutputError::RollupUnsupported). This is the interface #190 asks for. Supporting roll-up reads in the engine is a separate feature.

Checked, not a bug: rate/increase. sketch-bench's review asked whether MultipleIncrease can be fed several series under one key. An IncreaseAccumulator tracks one counter, so interleaved series would read as resets.

• In ASAPQuery, sum/min/… over rate/increase is not collapsable (get_is_collapsable), so those queries never match.
• A matched rate(x[w]) / increase(x[w]) keeps every label (build_query_requirements_promql: "OnlyTemporal preserves all labels").
• So MultipleIncrease is always keyed per series, and that's correct.