test(planner): cover summary-maintenance lifecycle end to end

[zzylol]

Stacked on #318.

Why

The lifecycle implementation crosses several public boundaries: normalized workload input, PromQL lowering, semantic candidate discovery, lifecycle-aware global selection, post-ASAP materialization, and the emitted deployment guarantee. Unit tests cover those pieces independently, but they do not prove that the real public APIs compose correctly.

This PR adds one focused integration test that exercises that complete path without reaching into private planner internals.

What this PR adds

A new integration test:

crates/integration-tests/tests/summary_maintenance_lifecycle_e2e.rs

The test covers this pipeline:

QueryWorkload
  -> workload validation
  -> PromQL batch lowering
  -> default replacement-strategy construction
  -> workload plan-space search
  -> lifecycle-aware global candidate selection
  -> selected DAG materialization
  -> summary-maintenance lifecycle planning
  -> SummaryMaintenanceLifecycleGuarantee assertions
  -> rejected-alternative assertions

Workload fixture

The fixture models a dashboard query:

quantile_over_time(0.99, latency[5m])

with an explicit epsilon = 0.01 accuracy requirement.

The normalized workload deliberately contains two entries for the same query text:

• one ad-hoc, one-time batch entry; and
• one predictable real-time dashboard entry repeating every second.

The lifecycle call explicitly binds the searched target to normalized workload entry index 1, the repeating dashboard consumer. This verifies that the public root-to-workload binding added in the preceding PRs is honored instead of accidentally using the unrelated batch entry.

The data workload declares:

• DataArrival::ContinuouslyIngesting;
• an observed ingestion rate of one update per second;
• observation time equal to NOW_MS; and
• a 60-second freshness window.

Planning uses a 100-second horizon. A one-second query interval therefore derives exactly 100 expected reads.

Runtime and cost-model fixture

FullyCostedRuntime supplies complete lifecycle cost evidence:

Cost input	Value
Build state	10
Maintain one update	1
Read/finalize state	1
Retain state for one second	0.1
Retire state	1

It also advertises support for incremental update, merge, and deletion. Deletion support is relevant because the dashboard is classified as real-time; the fixture remains valid if a moving-window summary requires expired input to be removed.

The target runtime lifecycle flags intentionally allow only:

• Ephemeral; and
• ContinuouslyMaintained.

Prepared and Shared are disabled so the test can verify that legal candidate selection and rejected-alternative reporting coexist in the same deployment.

Under the fixture’s numbers:

ephemeral = 100 reads * (10 build + 1 read + 1 retire) = 1200

continuous = 10 build
           + (100 seconds * 1 update/second * 1 maintenance)
           + (100 reads * 1 read)
           + (100 seconds * 0.1 retention)
           + 1 retire
           = 221

The fully costed continuously maintained alternative is therefore cheaper than rebuilding an ephemeral state for every dashboard evaluation.

raw_query_recompute_cost is intentionally not supplied by this fixture, so this test focuses on lifecycle-aware summary selection rather than the separately covered raw-fallback comparison.

Exact APIs exercised

The test uses the same public entry points available to an integration:

1. QueryWorkload::validate
2. lower_promql_batch
3. default_strategies_with
4. search_workload_with
5. global_selection_with_summary_maintenance_lifecycles
6. materialize_with_summary_maintenance_lifecycles

No internal helper constructs the selected summary or lifecycle directly.

Assertions

The resulting plan must prove all of the following:

• raw recomputation was not selected;
• expected demand is exactly 100 reads over the horizon;
• exactly one unique summary deployment was materialized;
• the selected lifecycle is ContinuouslyMaintained;
• the selected evaluation schedule is PerUpdate;
• the selected maintenance mode is Incremental;
• the prepared alternative is retained in the explanation and rejected with RequiresPredictableOneTimeQuery; and
• the shared alternative is retained in the explanation and rejected with UnsupportedByRuntime.

Together, these assertions verify both the winning physical contract and the audit trail for alternatives that did not win.

Scope

This is a test-only PR. It does not add planner behavior or change production APIs. The lifecycle DAG export and viewer assertions are added by the next PR, #313.

Verification

cargo test -p asap-integration-tests --test summary_maintenance_lifecycle_e2e

Expected result: one end-to-end lifecycle test passes.

Stack

Base: #318. Next: #313.