fix(s1-rtc): prepare the registration and validation paths for the data-model v0.11.0 pin - #413

The render extension requires `renders` on the item object; data-model #216 moved it there and
writes a temporary `properties` mirror so this repo keeps working across the relocation. Three
consumers read the old location: `register_per_acquisition` subscripted it (a hard KeyError once
the mirror goes), `register_v1_s1_rtc` and `register_v1` used `.get` and would silently lose the
config — which turns `_reorient_item_to_orbit` into a no-op and ships the preferred orbit's render
on every dual-orbit cube.

One helper, `register_v1.renders_blocks`, returns every live copy, root first. Reading the first
survives the mirror's removal and still reads items registered before the move; rewriting *all* of
them is what `_reorient_item_to_orbit` needs, so the root and the mirror cannot disagree.

Also corrects two comments that still described the single `(0.0, 0.2)` rescale the builder
replaced with a per-band stretch.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CHpM7QqgsF4jzhPxUxdU7V

Two more silent readers of the old location go with it: the catalog migrations
`align_visualization_links` and `add_xyz_link` in operator-tools, which on a miss report
"nothing to align" rather than failing.

`_reorient_item_to_orbit` now also moves `renders.rgb.assets`, which #216 added and which names
one orbit's γ⁰ asset: reorienting the expression alone left the descending preview advertising
the ascending asset on every dual-orbit cube.

`--tile-id` had no validation: the cube path is built straight from it, and the STAC builder only
rejects a bad store name at register time — i.e. after a multi-hour ingest has already written
`s1-rtc-<typo>.zarr`. data-model #216 makes that rejection a hard raise, so a typo leaves an
orphaned cube on S3. Validate it where the collection is already validated, before any subprocess.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CHpM7QqgsF4jzhPxUxdU7V

…nate name

Two defects in the structural gate, both reproduced against real stores built by the pinned
writer:

* `time` was missing from the tolerated coordinate names, so a CURRENT-generation store reported
  FAIL — five `extra_forbidden` errors, one per overview level. The gate has been crying wolf on
  every store it validates.
* after the pin bump a genuinely pre-#192 cube (no `time` on r20m..r720m — the ~170 published
  ones) fails a different way, `value_error` from the #192 coordinate check, which the name-based
  allowlist cannot see: WARN today, FAIL tomorrow.

Tolerance is now keyed to `eopf:writer_schema`, written at store creation from #216 on. Absent =
pre-#216 cube, so known drift is WARN; present = a generation that emits all of this, so any
validation error is a real defect. Verified across the matrix (current-gen, pre-#192, pre-#192 +
stamp) against both the pinned data-model and the PR #216 tip.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CHpM7QqgsF4jzhPxUxdU7V

The tolerated coordinate-check failures are matched in full, not by the shared "must contain
coordinate arrays" wording: the library raises that for four group kinds, and a substring match
also swallowed "Native resolution dataset must contain coordinate arrays ['x', 'y',
'spatial_ref']" — a cube with no georeferencing at all — passing it as WARN on every unstamped
store, i.e. the whole published archive.

From eopf-geozarr 0.11.0 `ingest_s1tiling_acquisition` refuses an append whose
`time` precedes the cube's last slice, and it grew `allow_out_of_order` to say
otherwise. `ingest_v1_s1_rtc.py` never passed it, so two legitimate cases became
hard failures of the Argo step:

  - backfilling an older scene into an existing cube;
  - appending at all to a cube built by the OLD discovery order, which sorted by
    (platform, tile, orbit_dir, rel_orbit, acq_stamp). Platform dominated the
    timestamp, so every cube built from a mixed S1A/S1C archive is non-
    chronological and each future append is out-of-order by construction --
    i.e. permanently un-appendable without this flag.

Plumbed as `--allow-out-of-order` through `run_ingest` and `ingest_all`, default
off, so an unexpected inversion in a routine cron run still fails loudly: there
it means the discovery order moved under us, which is worth stopping for. The
existing call-arg assertions now pin the default explicitly.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…the URI

The non-`rewrite_root_geo` consolidation branch inlines what `consolidate_s1_store`
does, but dropped two of its preconditions:

- It consolidated over `report.orbits`, captured from the pre-drop read-only handle —
  i.e. THROUGH the store's consolidated metadata. The library re-enumerates with
  `use_consolidated=False` precisely because an orbit group appended since the last
  consolidation is absent from a stale root block. The re-derive loop walks the fresh
  post-drop handle, so such an orbit was re-derived and then left unconsolidated, and
  readers opening it standalone fall back to a listing — the #203 defect this migration
  exists to fix.
- It passed the raw href-derived URI. `consolidate_s1_store` normalizes first, which
  matters on OVH S3 ("sensitive to double slashes").

The store is now opened `use_consolidated=False` and `report.orbits` is refreshed from
the post-drop listing, so the reported, re-derived and consolidated orbit sets are the
same set, and both consolidate calls take the normalized path.

Also: `--rewrite-root-geo` was a silent no-op on any store already carrying the
completion marker — the early return fires first. Once the fleet is migrated that is
every store, so an operator would get `already-current=N, derived=0` and no root
rewrite, with nothing saying the flag was ignored. It now warns. (Acting on the flag
instead would make an idempotent no-op path write to production roots; that is a
separate decision, not a silent one.)

Tests: a store whose consolidated root omits an orbit still gets that orbit enumerated
and consolidated; the ignored flag is reported.

Co-Authored-By: Claude Opus 5 <[email protected]>

The manifest carried a ⚠ comment saying `pr-413` (and any moving tag) must never drive
a real run. A comment cannot stop a submit: `imagePullPolicy: Always` plus a moving tag
means a `dry_run=false` run can pull a different build than the one the dry run
validated, against production cubes on a bucket with S3 versioning OFF.

The template now exits 1 before the driver starts when the image tag is `pr-*` or
`latest` and `dry_run` is not "true" — the bound is a feature of the tool, not a note in
the header. `PIPELINE_IMAGE_VERSION` is exported so the guard can read it.

The test runs the template's own script body under bash with a stub `python` on PATH,
so the control is exercised rather than assumed: refused on every moving tag with
dry_run=false, allowed for dry runs, out of the way for a `sha-<main-sha>` tag. It also
pins the manifest's safe defaults (dry_run true; allow_no_backup, rewrite_root_geo and
rollback false).

Co-Authored-By: Claude Opus 5 <[email protected]>