[Scoping] Second prediction store / partner — sample-bearing, multi-target, cm+pgm with reconciliation #97

Context

A second prediction store / partner (beyond UN FAO) is coming soon. Per WET-before-DRY (maintainer, explicit): build it as its own partner track — a sibling package to unfao/, deliberately duplicated and quirky. Do NOT generalize delivery/ or abstract a partner framework yet. Generalize only after a 3rd/4th store reveals the real commonality. This issue scopes the requirements + the open architectural decisions; it is not a generalization epic.

This also makes the rename (#96) more obviously right: a second partner = a multi-partner delivery layer, not "postprocessing".

Same as FAO (reuse, don't reinvent)

• PGM forecasts, sample-bearing (draws) — the same pandas→frames work as epic [EPIC] Push pandas to the seams: views-frames migration for sample-bearing predictions #85 / views-models#143. This store is a second forcing function for native (N,S) samples.
• All targets — sb, ns, os (this applies to FAO too).

Different from FAO

1. Uncertainty products: the delivery must carry exceedance probabilities + HDI + MAP (the views_frames_summarize outputs), not just point estimates.
2. Two LOAs with dedicated models + reconciliation: FAO's country numbers are aggregated up from PGM. The new store has dedicated country (cm) models AND dedicated grid (pgm) models, plus reconciliation between them so they map. views-frames already supports both levels (SpatialLevel.CM / SpatialLevel.PGM) and reconciliation lives in views_frames_reconcile.

Open architectural decisions (the crux)

• D1 — where does cm↔pgm reconciliation run?
  Options: (a) upstream, in the forecasting/ensemble stage, so the store holds already-reconciled forecasts (consistent with reconciliation having been moved OUT of this repo into views_frames_reconcile); (b) here, invoking views_frames_reconcile on the delivered cm+pgm frames; (c) the API.
  Recommendation: (a) upstream if the pipeline allows; if the store delivers cm+pgm unreconciled, prefer (b) here over (c) the API — reconciliation is a producer-side data op (D-07), not a serving concern. Either way the algorithm is views_frames_reconcile; the question is the call site, not a re-implementation.

• D2 — where does summarization (HDI/MAP/exceedance) run?
  Default platform contract (draws-preservation, FAO delivery path is point/DataFrame-based — won't carry rusty_bucket's pooled draws #45) = deliver draws uncollapsed, summarize at the edge (the consuming API). Decide per the new partner's contract: does it ingest draws (like faoapi → API summarizes, this repo unaffected) or want pre-summarized data delivered (→ this repo calls views_frames_summarize before upload)?

Things to do now (WET-aware — no premature abstraction)

• Do the pandas→frames migration ([EPIC] Push pandas to the seams: views-frames migration for sample-bearing predictions #85) with both stores in view — the new store needs native (N,S) samples just like fix(register): C-62 — corrected measurements and the actual removal path #143.
• build_prediction_frame (S1, S1 — frames.py: generalize to_prediction_frame to S>1 (pandas→frames) #86) currently hardcodes SpatialLevel.PGM; the cm path needs the level declared — a small change when the cm track is built (don't pre-build it).
• Keep store identity out of hardcoded blocks (D-09 standing rule) as both tracks evolve; the DeliveryProfile (C-33) may land naturally with store Development #2.
• Build the new store as a sibling partner package, not by generalizing unfao/.

Refs

C-33 / D-09 (store identity / DeliveryProfile), #45 (draws / API summarization), epic #85 (#86 S1 done, #87 S2 done — pandas→frames), views-models#143 (rusty_bucket draws), views_frames_reconcile + views_frames_summarize (the algorithms), #96 (rename).