Specify which CPM root metadata is carried through to GeoZarr output (stac_discovery is stale by construction) #257

Problem

The converter copies the input product's root attributes through to the output verbatim (write_store_root_stac_metadata, called from simple_root_consolidation). For CPM products that means other_metadata, processing_history and stac_discovery land in the GeoZarr output unchanged.

None of it is specified anywhere. We do not state what we carry through, what we drop, what we rewrite, or what a consumer may rely on. The result is metadata that is stale by construction.

Evidence

EODC's 31 August S2 L2A product (built from the cpm-geozarr-eodc branch):

• the output root carries stac_discovery with 83 assets, each {href, title} only;
• every href points at an input path, e.g. /conditions/geometry/sun_angles;
• none references the pyramid levels the conversion creates — r120m, r360m, r720m appear nowhere in it.

So the store ships a STAC object describing a layout the store no longer has, with no marker saying so. A consumer reading it gets a wrong answer rather than no answer.

Why it matters now

1. Correctness. A copied-through object that contradicts the store is worse than an absent one.
2. Source of truth. This is the same question as EOPF-Explorer/coordination#302 — whether the in-store object, the producer's catalogue, or our catalogue is authoritative. Copying an unmodified input object into a restructured output quietly asserts the first, while making it untrue.
3. A latent collision. write_store_root_stac_metadata does an unconditional root.attrs.update() after write_store_root_geo_metadata has written the minispec footprint. Current CPM inputs carry no spatial:bbox / proj:code / zarr_conventions at the root, so nothing collides today — but we have asked CPM to start declaring zarr_conventions there (https://gitlab.eopf.copernicus.eu/cpm/eopf-cpm/-/issues/1189). When that lands, this silently overwrites our computed footprint.

What to decide

• Which input root attributes we carry through, drop, or rewrite — written down, not implicit.
• For stac_discovery specifically: rewrite the assets to describe the output layout (pyramid groups, per the multiscales convention), replace it with a stac:link to the authoritative catalogue, or drop it. Copying it unchanged is the one option that is definitely wrong.
• Make the root-attribute merge explicit about precedence, so computed GeoZarr metadata is never silently overwritten by passthrough.

Related

• Cpm geozarr eodc changes #247 introduced the passthrough — flagged there, deliberately not blocking it.
• EOPF-Explorer/coordination#302 — STAC source-of-truth decision.
• https://gitlab.eopf.copernicus.eu/cpm/eopf-cpm/-/issues/1189 — asking CPM to adopt the STAC Zarr Convention.
• There are also three overlapping root-writing helpers now (write_store_root_geo_metadata, write_store_root_bbox which merely wraps it, and write_store_root_stac_metadata); worth consolidating while doing this.