Record the MIP era on metric values instead of deriving it downstream

Records the MIP era on metric values at write time. The API currently calculates it on the fly and it is used to show CMIP6 or CMIP7 results.

## The problem

A metric value does not say which MIP era produced it and diagnostics (generally) don't include a label.

In the ref-app `backend/src/ref_backend/core/mip_eras.py` maps `Dataset.dataset_type` onto an era label, and `core/reader_values.py:annotate_mip_eras` stamps that label onto every model value on the way out.

This requires an extra join, but its something that we know at write time.
The mip_era is a property of the data, not a presentation concern.

## Proposal

Stamp `mip_era` as a dimension on scalar and series metric values when they are ingested, derived from the execution's input datasets.

Proposed rules:

- A diagnostic that emits its own `mip_era` keeps it.
- A diagnostic/execution that spans CMIP6/7 has no label.
- An execution with no CMIP input gets no era (obs), rather than being dropped by consumers that filter on one

`mip_era` also needs registering as a dimension in the controlled vocabulary so it survives `MetricValue.build`, which rejects unknown dimension keys.

Backfill old values using the algo from the app.

## Follow-up

Once this lands, `ref-app` can drop `annotate_mip_eras` and query the dimension directly.

Start with ref-app/backend/src/ref_backend/core/mip_eras.py and core/reader_values.py:annotate_mip_eras to understand the existing era mapping and downstream annotation. Trace metric ingestion, MetricValue.build, and controlled-vocabulary registration, then implement the stated rules for scalar and series values and backfill old values. Done means values carry the correct mip_era dimension, mixed or observational inputs remain unlabeled, and ref-app can query it directly.

Written by the indexing model from the issue text.