feat(workload): normalize query demand and data evidence

[zzylol]

Stacked on #300.

Why

Summary-maintenance lifecycle planning decides when materialized summary state
is created, retained, shared, updated, and retired. Those decisions require
normalized evidence about query recurrence and timing, requested latency and
accuracy, data arrival, and evidence freshness.

Before this PR

Planner inputs lacked enough explicit evidence to decide whether summary state
should be built for one query, prepared ahead of time, shared across reads, or
maintained as data arrives.

After this PR

A scheduled dashboard query becomes normalized requirements explicitly bound
to its plan root; SQL and PromQL share the same planner-facing model. This PR
only supplies the workload evidence. #316 uses it to enumerate the concrete
summary-maintenance lifecycle alternatives.

What and how

• Models recurrence, accuracy, latency, predictability, and time selection.
• Tracks freshness-aware ingestion, cardinality, and distribution evidence.
• Adds explicit root-to-workload bindings.
• Defines every public workload axis with concrete rustdoc examples.
• Does not enumerate summary-maintenance lifecycle alternatives.

Verification

• Workload and frontend unit suites
• cargo test -p asap-types --doc
• Workspace check, formatting, and clippy

Stack

Base: #300. Next: #316.