test(example4): B1 vs B2 as model-relative invariants (Q49)

[zzylol]

Stack: Wave 3 chain: #605 → #607 → #608 → #609 → #610 → this PR

Rebased on main d4869a7 (DF 54).

Problem

Example 4's spec says B1 (tumbling KLL panes built at ingestion time) is never costlier than B2 (rebuild every pane from raw samples at each evaluation). The built-in model contradicts that for Pattern B, so both tests were #[ignore]d:

• B1 keeps 6 panes of 1M per-series KLLs, about 6.1 GB, which costs 768.58 cost/s.
• B2 costs 5.17 cost/s, or 45.17 when raw retention is charged. It is over the 200 ms latency limit anyway.

Q49 (a): write the tests as invariants that follow from the model, and add a workload where B1 actually wins.

What the model implies

B1 keeps one KLL per series per pane for as long as the window lasts. B2 keeps no state, but it reads the window's raw samples at every evaluation. It pays to retain those samples only when the deployment doesn't keep raw data (#609). So B1 wins only when its panes are smaller than the raw samples they cover, and keeping those samples would otherwise be charged to the plan. When raw data is kept, B1 wins only if B2 breaks the latency limit.

Workload (p99 quantile_over_time)	Raw data kept	B1 cost/s	B2 cost/s	Test
Pattern B: 1M series, 15 s sampling, 5 m window, every 1 m	yes	768.58	invalid (310 ms > 200 ms)	stage3_b_rebuilding_a_million_series_breaks_the_latency_bound
10k series, 15 s, 5 m, every 1 m	yes	7.69	0.05	stage3_b_kept_raw_data_makes_rebuilding_cheaper
10k series, 15 s, 5 m, every 1 m	no	7.69	0.45	stage3_b_panes_larger_than_their_raw_data_lose
1k series, 1 s, 1 h window, every 10 m	no	0.90 (selected)	7.30	stage3_b_panes_smaller_than_their_raw_data_win

The tests check which option is cheaper, not the numbers. The numbers above are from the illustrative v2 calibration.

Changes

• planner_layering_example4.rs: removes the two ignored tests stage3_b_rebuilding_every_window_costs_most and stage3_b_prefers_ingestion_time_tumbling_windows, and adds the four tests above, a pattern_b_variant workload builder, and run_with_raw_data.
• planner_layering_common: adds run_stages_with, which plans with the given deployment inputs. run_stages calls it with the executor's inputs.

Test plan

• cargo fmt --check and cargo clippy -p asap-integration-tests --all-targets -D warnings are clean.
• cargo test -p asap-integration-tests: 209 passed, 0 failed.

🤖 Generated with Claude Code