Migrate the r2darts2 family to prediction_format: prediction_frame — deferred from #489

[Polichinel]

Deferred from #489 / PR #491 (epic #488), where the eleven pgm r2darts2 models arrived from staging_202608 with prediction_format: "prediction_frame" and were set back to "dataframe".

Why they were set back

On staging the value was applied by one commit (2dfe6d75, "pfs", 2026-07-22) to four of them and inherited from the scaffold template by the other seven — but none got the keys the PredictionFrame contract needs (n_posterior_samples, hp regression_targets), and staging's own tests/conftest.py lists all eleven under _INCOMPLETE_PFE_MODELS ("has not completed the PredictionFrame contract migration"). development has no such skip-list; test_pfe_production_readiness.py would have failed 22 times. All 31 cm r2darts2 siblings run on "dataframe", and 13 of them passed calibration on fimbulthul on 2026-09-19 that way.

What this issue is

The actual migration, for all 42 r2darts2 models (31 cm + 11 pgm), when someone decides the r2darts2 engine is ready for the frames-native path:

• r2darts2 0.2.x's prediction output must satisfy the PredictionFrame contract on the DataFrame → frame boundary (pipeline-core ADR-018; C-136 says the pandas-free evaluation path is "built, tested and unreachable").
• each config: prediction_format: "prediction_frame", n_posterior_samples (point models: evaluation_mode: "point" + aggregate_method, cf. All 9 point baselines rejected by CoreConfigSniffer: evaluation_mode='point' without aggregate_method (since #220, 2026-06-27) #477), hp regression_targets.
• test_pfe_production_readiness.py then judges them — no skip-list.
• ADR-064's entity-coverage check exempts the PF path today (pipeline-core); check that stays true or that the PF path has its own.

Not before #490 (maturity for the 31) lands. Not part of epic #488's definition of done.

[Polichinel]

The half-migrated configs may be biting right now, on a branch — views-pipeline-core#530

From the pipeline-core side, investigating #530 ("No pred files generated", Dylan, rude_boy). Inference, not yet reproduced, but this issue looks like the context for it.

bright_star — the constituent that fails — exists only on origin/staging_202608: level: "cm", algorithm: "NBEATSModel", prediction_format: "prediction_frame", pinned views-r2darts2>=0.2.0. That is exactly the state this issue describes being set back on development.

Why it fails. rude_boy runs on pipeline-core's legacy DataFrame-tier ensemble manager, which looks for predictions_*.parquet files. A prediction_frame child writes numpy directories and writes the Track B parquet only when skip_predictions_delivery is False. So the child succeeds, exits 0, and the DF-tier parent finds nothing and raises. Nothing errors; the two tiers simply cannot see each other.

Two things this adds to the issue as written:

1. A half-migrated config is not inert on a branch. The set-back on development is the right call, but any branch still carrying the staging value will fail this way the moment the model is used in a DataFrame-tier ensemble — with a message (No prediction files found for X after generation) that points at saving, not at the format mismatch. Worth noting in the issue so the next person who meets it does not debug the saver.

2. There is now a reason to set prediction_frame that has nothing to do with this migration. views-r2darts2#55: entity_id defaults to "country_id" regardless of level on the DataFrame boundary, so every pgm r2darts2 model's predictions were mislabelled and refused. The PF path labels from the dataset and is correct. views-r2darts2 suggests — as a hypothesis, and we have asked Dylan directly on Aggregate calibration: a single trained model under-predicts totals ~10x with ~0% interval coverage — does pooling fix it? #530 — that PF may have been set on bright_star to dodge fix catalog script #55, on the same day fix catalog script #55 was filed. If that is happening, it is a workaround that swaps a wrong label for a tier mismatch, and it will keep happening until fix catalog script #55 ships.

Unchanged and still true: the bullet in this issue that ADR-064's entity-coverage check exempts the PF path. It still does (pipeline-core 3.3.0, ADR-064). If the r2darts2 family does migrate, that exemption should be revisited in the same change, not after — views-r2darts2's own entity filter (filter_entities_at_end, present from 0.2.2, installable from 0.2.3) covers the ingest side but not the predict side.

Pipeline-core will separately add a config-time refusal for a constituent whose prediction_format disagrees with its ensemble's tier, so this stops being discoverable only at runtime.