feat(dataset): optional satpy-backed reader for geostationary/polar native L1-L2 formats (SEVIRI/FCI/OLCI/AHI)

[MAfarrag]

Summary

Add an optional, satpy-backed reader that decodes native geostationary / polar instrument products —
Meteosat SEVIRI (MSG), MTG-I FCI, Sentinel-3 OLCI/SLSTR, Himawari AHI (HSD) — into a pyramids Dataset /
array with georeferencing and standard CF-style metadata. Gated behind an optional extra (e.g. [satpy]) so
it never enters the core dependency set.

Motivation

pyramids currently has no path to decode these native instrument formats. Downstream consumers fetch the raw
granules but have nowhere in pyramids to read them:

• EUMETSAT products (HRSEVIRI L1.5, MTG-I1 FCI L1c, Sentinel-3 OLCI/SLSTR).
• Himawari AHI HSD, shipped raw and deferred to pyramids for decode.

satpy is the mature (~1k-star) reader ecosystem for exactly these sensors; the aim is to bridge to it for
decoding, not to re-implement readers.

Scope alignment (docs/SCOPE.md)

Per §3 / §6.1, reading a format is always in scope, even an exotic one — the same category as the GRIB
reader (S8) and the NetCDF/HDF readers. A satpy-backed reader is format support.

In scope (this issue)

• Open a native scene/file → return arrays / a Dataset (or NetCDF / DatasetCollection as appropriate)
  with georeferencing + standard metadata passthrough.
• Optional dependency behind an extra; core install unaffected.
• Dependency direction is fine: pyramids may take satpy as a third-party optional dep (pyramids must not
  depend on its domain consumers, but satpy is not one).

Explicitly OUT of scope (belongs in the consumer, not here)

• satpy composites (RGB recipes), radiometric calibration choices, sensor-specific enhancement,
  and band-order semantics. These are domain value-semantics — the same class as the deprecated
  convert_units (S1) and the Sentinel-2 [2,1,0] RGB fallback (S5) — and belong in the domain package or
  caller-supplied. The reader decodes to arrays + standard metadata only; it does not decide what a pixel
  means.

Notes

• Suggested surface: a from_satpy(...) entry point or engine dispatch behind the existing readers —
  implementer's call.
• Driven by the earthlens.eumetsat and earthlens.jaxa (P-Tree) backends, which fetch these products raw.

[MAfarrag]

Cross-reference: this is already scoped in the internal plan planning/earthlens-providers/pyramids-tasks-implementation.md as PY-2 (satpy_bridge.py, read_scene(...), [satpy] extra). Its recorded state there is Open, current state Nothing — no satpy import anywhere, gated on decision D3 (whether GPL/LGPL deps like satpy/pyresample/trollimage/pyspectral are acceptable — the plan notes they likely are, since pyramids is GPLv3, but it wants maintainer confirmation). This issue just surfaces that item as a tracked GitHub issue; the D3 licensing call is the thing to resolve first.