Choose costed sliding-window materialization layouts

[zzylol]

A semantic sliding window was previously compiled only as non-overlapping panes, and the compiler overloaded window_size with the chosen pane width. That made full overlapping windows impossible to cost or install and blurred query semantics with storage layout.

This change makes the backend choose among typed physical layouts while keeping the Planner DAG semantic:

• adds catalog-visible Pane, FullWindow, and exact HierarchicalRollup layouts;
• keeps window_size, slide_interval, and pane_size independent;
• includes the physical layout in SummaryDefinitionId identity and catalog bindings;
• validates layout divisibility and framework compatibility before planning or installation;
• passes every concrete implementation's measured weighted cost to Planner, with auditable CPU, memory, storage, network, and scan components;
• computes retention according to the selected layout;
• emits the selected layout to precompute and collector plans without stringly typed state_layout fields.

For a 60-second window evaluated every 10 seconds, the same post-ASAP DAG can now choose either six 10-second panes or one complete 60-second state produced every 10 seconds. Tests demonstrate selection of the full window when its query-frequency-adjusted cost is lower, selection of panes when update/storage cost dominates, multiple valid slide frequencies, and fail-closed non-divisible layouts.

Validation:

• cargo test -p control_plane --lib --quiet (712 passed)
• cargo test -p asap_types --quiet (70 passed)
• cargo check -p data_plane
• git diff --check

Stacked on #579 because the installed precompute plan must retain the executable DAG bindings alongside this physical layout.