feat(summary-maintenance): define lifecycle alternatives

[zzylol]

Stacked on #312.

Why

A logical summary plan does not determine how its materialized state is operated. A summary-maintenance lifecycle is the physical policy for when one summary state is created, retained or shared, updated as data arrives, and retired. It is narrower than the end-to-end data lifecycle and independent of query recurrence: recurrence is workload evidence used to choose a lifecycle.

SummaryMaintenanceMode is orthogonal: it says whether the selected deployment builds the state directly or updates it incrementally.

Before this PR

Candidates did not distinguish ephemeral, prepared, shared, and continuously maintained summary state, and the generic lifecycle naming did not identify what was being managed.

What this PR defines

Physical lifecycle vocabulary

• Ephemeral: build a fresh state for each invocation and retire it after that invocation.
• Prepared { activate_at, retire_at }: create state ahead of a predictable one-time execution and retain it for the declared preparation window.
• Shared { retention }: retain one state for reuse by multiple reads over a bounded horizon.
• ContinuouslyMaintained: keep retained state current by applying arriving-data updates.

These are physical deployment choices. They do not change query semantics or become properties of the logical SummaryNode.

Orthogonal execution contracts

• SummaryMaintenanceMode::{DirectBuild, Incremental} describes how state is produced or refreshed.
• EvaluationSchedule::{OneShot, PerUpdate, OnRead} describes when its operator runs.
• OutputRepresentation::{PlainRows, SummaryState, FinalizedValue} describes what the deployment exposes to its next consumer.

Keeping these axes separate avoids treating state lifetime, update mechanism, execution timing, and output form as one overloaded enum.

Runtime capability contract

SummaryMaintenanceLifecycleCapabilities independently declares whether the target runtime can orchestrate ephemeral, prepared, shared, and continuously maintained deployments. Support only makes an alternative eligible for consideration; workload evidence and complete cost evidence are still required before it can be selected.

Cost-model contract

SummaryMaintenanceLifecycleCostInputs defines the primitive inputs used to compare alternatives:

• one-time state build cost;
• maintenance cost per arriving update;
• summary read/finalization cost;
• retention cost per second; and
• one-time retirement cost.

Every input is optional. Missing evidence produces an uncosted alternative, never an assumed zero.

Alternative, deployment, and plan outputs

• SummaryMaintenanceLifecycleAlternative records the lifecycle and maintenance mode considered, its total cost when known, assumptions, and a typed rejection reason.
• SummaryMaintenanceDeployment records one unique reachable SummaryAgg, all alternatives considered for it, and the cheapest selectable lifecycle plus its execution/output contract.
• SummaryMaintenanceLifecyclePlan records the materialized root, its unique summary deployments, the optimization horizon, aggregate evaluation rate, and fresh update rate.
• Shared Rc<SummaryNode> state is represented by one deployment rather than being charged once per graph occurrence.

Typed rejection reasons cover unsupported runtime behavior, missing predictability, insufficient reuse, missing horizon, incompatible data arrival, stale/missing ingestion rate, and incomplete cost evidence.

Workload evidence and costing rules

The planner derives expected reads, evaluation rate, update rate, data-arrival mode, and any preparation window from #312's normalized QueryWorkload model. In particular:

• one-time invocation counts cost ephemeral reads directly;
• fixed intervals, explicit schedules, and fresh demand estimates contribute recurring demand;
• shared and continuous alternatives require an explicit horizon;
• prepared state requires a predictable one-time execution with a known preparation window;
• continuous maintenance requires continuously arriving or mixed data plus a fresh ingestion rate; and
• unknown recurrence, update, or cost evidence remains unknown and cannot make a long-lived alternative win.

For each unique summary state, plan_summary_maintenance_lifecycles enumerates all four lifecycle shapes and selects the cheapest legal, fully costed alternative. Global candidate selection and the stronger legality checks are intentionally layered into #317 and #318.

Code organization

• Defines the post-ASAP vocabulary in crates/types/src/post_asap/summary_maintenance_lifecycle.rs.
• Defines enumeration, workload aggregation, costing, rejection, and per-materialized-plan selection in crates/asap-aware-mapping/src/summary_maintenance_lifecycle.rs.
• Adds lifecycle cost inputs to the CostModel extension surface.
• Uses the explicit summary_maintenance_lifecycle name throughout so it cannot be confused with query or source-data lifecycle.

Verification

• cargo test -p asap-aware-mapping summary_maintenance_lifecycle --no-fail-fast
• cargo clippy -p asap-aware-mapping --all-targets -- -D warnings
• Full stacked workspace tests and clippy pass.

Stack

Base: #312. Next: #317.

[milindsrivastava1997]

are ephemeral and prepared mutually exclusive?
what about continuously_maintained and ephmeral?

[zzylol]

They are mutually exclusive as selected lifecycles for one deployment, but not as runtime capabilities. These flags describe the set of alternatives a runtime supports, so a runtime may support both Ephemeral and Prepared, or both Ephemeral and ContinuouslyMaintained; the planner still selects exactly one SummaryMaintenanceLifecycle per deployment. I renamed the fields to supports_ephemeral, supports_prepared, supports_shared, and supports_continuously_maintained, and documented this distinction.

[milindsrivastava1997]

what's an execution boundary

[zzylol]

It meant the interface between a summary-maintenance deployment and the downstream query operator consuming its output. The phrase was too vague, so I replaced it with a direct description: the deployment provides ordinary rows, reusable summary state, or a finalized result value to its downstream query operator.

[zzylol]

I clarified consumer as well: it is the next operator in the execution plan that reads the summary output—for example, Estimate in SummaryAgg -> Estimate. The comment now defines that relationship directly before listing the possible output representations.