feat(erp): match bounded multi-family observations

[zzylol]

Why

Observed production data rarely belongs exactly to one named distribution. Hard-classifying it as uniform or Zipf can select an unrelated empirical profile for mixed, truncated-tail, drifting, or out-of-distribution inputs.

What

• Represent runtime observations as empirical features plus multiple candidate distribution fits.
• Match only fits with acceptable goodness, confidence, catalog distance, and best/second-best margin.
• Preserve exact dataset identity as the highest-confidence path.
• Document custom-dataset approximate matching and Hybrid theoretical/exact fallback.

How

Planner evaluates every retained fit against compatible benchmark shapes, combines cardinality, parameter, feature, temporal, and evidence distances, then applies ambiguity and OOD gates before ERP accuracy/resource selection. It does not require the observer to name one family first.

Before this PR

The v1 contract carried one family and parameter map. The backend thresholded one rank-frequency slope into uniform or Zipf, and Planner only matched equal families.

After this PR

A caller can retain competing fits and their quality evidence. Poor or ambiguous observations produce an ERP miss, allowing Hybrid mode to use theoretical sizing and then exact execution.

Verification

• cargo fmt --all -- --check — passed.
• cargo test -p asap-aware-mapping erp --lib — 8 passed, including confident multi-fit selection and ambiguous/poor-fit rejection.

Limitations and follow-up

Backend feature extraction and sketch-bench canonical feature export require coordinated follow-up PRs. Current backend v1 observation remains the narrower uniform/Zipf compatibility stage until those land.

[zzylol]

Closing as a duplicate follow-up after #380 merged. Relative to current main, this PR contains only an older version of the ERP design-doc update. The more complete and implementation-aligned documentation is in #382.