Document adding new query workloads and reusing existing strategies with end-to-end examples

[zzylol]

Following #509, we need a design/extension guide for adding a new query workload to ASAPPlanner and explaining how it can reuse existing replacement strategies.

Requested documentation

• Define what adding a workload means: expressing a new workload through existing query languages and operators, versus adding frontend or semantic support for a previously unsupported workload.
• Specify the workload inputs and requirements: queries, batch/repetition structure, time/window semantics, accuracy, invocation/evaluation information, and relevant data-workload evidence.
• Explain how query semantics map to aggregation intents and logical operators, how resolution and canonicalization work, and what schema/identity/time information must survive lowering.
• Explain how existing strategies recognize the resulting IR and which requirements make them applicable. Show how to determine that no new strategy is needed, and how to identify an actual capability gap.
• Trace the workload through docs: propose workload-wide planning, summary sharing, and materialization #509's architecture: local alternatives, workload-wide sharing, physical/materialization alternatives, cost/accuracy/capability checks, selection, and execution.
• Describe the extension points, registration/configuration, validation, and tests required when genuinely new frontend or operator support is needed. Separate those changes from changes to strategies or primitive implementations.

End-to-end examples and acceptance

Include complete, reproducible examples for:

1. A new query workload handled by existing lowering and replacement strategies.
2. A multi-query or repeated workload that reuses/shares existing summary computation, including time/window and accuracy requirements.
3. A workload requiring an extension, showing the missing capability, the smallest required change, and its effect on strategy reuse.

For each example, show concrete workload input, IR/intents, applicable strategies, candidate plans, selection assumptions, execution inputs, and expected outputs. Link to tests where implemented and clearly identify proposed or missing behavior.

Reference: planning architecture proposed in #509.