docs(erp): explain multi-family shape matching

[zzylol]

Why

The ERP implementation now accepts an observation with multiple fitted distribution hypotheses, but the design document still described one preclassified family. That made the documented policy look like hard Zipf/uniform classification and left confidence and ambiguity handling as future work.

What

Document the two-stage policy: observe an empirical population, retain multiple family fits, reject weak or ambiguous fits, and match the selected fit to bounded sketch-bench ERP records. Clarify exact custom-dataset identity, the intended shape fallback, and the current backend boundary.

How

The document now mirrors the shared ErpShapeObservation and ErpShapeFit contracts. It distinguishes fit eligibility from ERP record ranking and describes the implemented order: confidence/goodness gates, ambiguity margin, family and parameter-schema compatibility, bounded shape distance, accuracy/runtime checks, cost, then stable record ID.

Before this PR

The document showed one erp_shape { family, parameters } for both benchmark and observation and said different families were never interpolated. Readers could reasonably conclude that runtime data was classified as one known distribution before matching.

After this PR

The benchmark record still declares its known generator shape. A runtime observation carries several approximate hypotheses with goodness-of-fit and confidence. Poor, ambiguous, and out-of-distribution observations fail closed to theoretical sizing or exact execution.

Verification

• Compared the document with ErpShapeObservation, ErpShapeFit, and select_multi_fit on current main.
• git diff --check passed.
• Runtime tests are not applicable because this PR changes documentation only.