feat(optimizer): select atomic costs by observed data shape

[zzylol]

Why

ASAPQuery's optimizer could load atomic sketch costs only by exact workload JSON. Evaluation and offline planning need the same bounded cardinality/skew profile-selection semantics used by the ERP production path.

What

• Attach an optional {cardinality, zipf_exponent, benchmark_events} shape to atomic-cost profiles.
• Select the nearest compatible profile with explicit sufficiency and distance bounds.
• Expose observed-shape selection in asap-optimizer-cli and candidate-gen-dump.
• Reject missing, malformed, cross-family, ambiguous, and out-of-bound evidence.

How

The selector uses the maximum normalized log2-cardinality and Zipf-exponent distance. Uniform and Zipf profiles never cross-match. The selected table continues through the existing exact (sketch, params) atomic-cost resolver.

Before this PR

Offline ASAPQuery optimization required an exact serialized workload selector and could not consume a runtime-observed data shape.

After this PR

Offline ASAPQuery evaluation can choose the same nearest benchmark scenario as the production ERP policy, then optimize over measured sketch costs.

Verification

• CARGO_NET_GIT_FETCH_WITH_CLI=true cargo test -p asap_planner optimizer::atomic_costs::tests — 16 passed.
• Full-stack, image, Docker, format/lint, and repository test CI pass.

Relationship to ASAPQuery-backend PR #581

Both PRs implement the same policy purpose: configure sketches from the closest sufficiently measured data shape. #581 is the production runtime-observation and ASAPPlanner path; this PR is the ASAPQuery offline optimizer/evaluation path. They share shape fields and distance semantics but are not a direct runtime call chain.

Limitations and follow-up

The CLI currently receives observed shape as a JSON artifact; live observation belongs to backend #581. A shared wire crate would remove the duplicated Rust shape types.