Deployment inputs: one bundle for cost model, accuracy model and capabilities — after #511

[zzylol]

Goal

#509 (Goal; "3. Plan selection") says the deployment supplies an empirical cost model, an empirical accuracy model and its execution capabilities, and selection rejects candidates needing a missing capability. The input structure is a TODO in #509.

Blocked on

Implementation of #511 (unified operator graph). Do not start before #511 is implemented.

Current state (main @107ab28d)

Input	Defined	Supplied	Default
PlanningModels{cost,accuracy,evidence}	asap-aware-mapping/src/pass/mod.rs:46-90	OptimizationInput.models / planner UserInput.models	builtin()
SummaryMaintenanceLifecycleCapabilities (lifecycle flags)	summary_maintenance_lifecycle.rs:60	plain value in LifecycleInput.capabilities, next to the clock and horizon	ALL
SummaryMaintenanceCapabilities (update/merge/delete)	summary_maintenance_lifecycle.rs:81	CostModel::summary_maintenance_capabilities	all false
ValueOperationCapabilities	cost_model.rs:96	three CostModel hooks (value_operation_capabilities → supports_value_operation → value_operation_support_evidence)	ALL
summary_support_evidence	cost_model.rs:882	CostModel hook	None

Notes:

• SummaryMaintenanceCapabilities is planner knowledge. Its docs say it describes what the summary algorithm can do, not what the deployment can do.
• ASAPQuery-backend still pins Planner rev f46cbf6c. It overrides value_operation_capabilities with the old field names and summary_maintenance_capabilities, and builds SummaryMaintenanceLifecycleCapabilities directly. Changes here only reach it when it bumps the pin.

Proposed (one concern per PR)

1. Move capabilities: SummaryMaintenanceLifecycleCapabilities from LifecycleInput into PlanningModels, with with_capabilities(); builtin() uses ALL. PlanningModels then becomes the single deployment-input bundle, and LifecycleInput keeps only the clock and horizon. No new struct. About 40 lines. Test: MajorPass with continuous-only capabilities rejects the other lifecycles with UnsupportedByRuntime.
2. Later: derive SummaryMaintenanceCapabilities from the physical kernels instead of a CostModel hook.
3. Later: collapse the three value-operation capability hooks into one.

Open questions

• Rename PlanningModels (e.g. DeploymentInputs)? Recommended: no for now.
• How docs: define unified operators and SQL/PromQL scalar boundaries #511's operator capabilities map onto these inputs.