Cloud radiative effects stores a different CERES-EBAF reference per model

The `cloud-radiative-effects` zonal mean series stores a separate copy of the CERES-EBAF reference for every execution, and those copies do not agree with each other.

For `lwcre` there are 96 distinct `reference_id` content hashes across the diagnostic, all labelled `CERES-EBAF-4-2-1`. The peak of the reference curve ranges from about 31 to about 46 W m-2 depending on which model the execution ran against.

A couple of examples from staging, both `esm-hist`, both `lwcre`:

| Model | Grid | `reference_id` | Peak (W m-2) |
| --- | --- | --- | --- |
| CanESM5-1 | g120 | `b819b793e5` | 45.7 |
| UKESM1-3-LL | g110 | `8e95d252ea` | 33.7 |
| MPI-ESM1-2-LR | gn | `6fe8e631bc` | 31.5 |
| ACCESS-ESM1-5 | gn | `ed65edd1a4` | 46.2 |

Reproduce with:

```
curl "https://staging.climate-ref.org/api/v1/diagnostics/esmvaltool/cloud-radiative-effects/values?value_type=series&statistic=zonal%20mean&limit=500"
```

Some spread is expected because the reference is regridded onto each model grid before the zonal mean is taken. A 15 W m-2 range on the tropical peak is far more than regridding alone should produce, so I suspect the reference is also being masked to the model's valid points. Worth confirming what the recipe actually does here.

This surfaces in the explorer as multiple black reference lines on one chart, because the frontend deduplicates references by content hash and the hashes genuinely differ. I've added a warning for now. Perhaps we should pull this chart.

Start with the cloud-radiative-effects values endpoint and the recipe it serves. Compare how CERES-EBAF references are regridded and masked for each model, using the listed staging executions to reproduce the differing hashes and peaks. Done means the cause is confirmed and the endpoint no longer exposes unjustified duplicate reference curves, or the behavior is documented as intentional.

Written by the indexing model from the issue text.