Implement modeler with grid domain support only

[chuckwondo]

Story 3 (PR 1): CoverageJSON modeler — Grid domain

Implements the modeler layer that converts a CoverageInput into a covjson-pydantic Coverage, scoped to the Grid domain (gridded rasters). Story 3 is split by domain type so each PR stays relatively small and independently reviewable; this is the first part. Part of #8; closes #17.

What's included

• modeler.py: to_coverage(coverage_input) and helpers, implemented as stateless module-level functions (no class). Builds the Grid Domain (x/y CompactAxis), spatial referencing, one Parameter per band, and range NdArrays, reusing the existing helpers.py utilities. Non-grid geometry and non-3-D data raise NotImplementedError until later PRs.
• input.py: CoverageInput now resolves bands at construction (synthesizing b1, b2, ... when none are supplied), so consumers always read a populated tuple and the default-band convention lives in one place. Added domain-independent guards: reject empty data axes and duplicate band names (both become CoverageJSON keys and would otherwise fail opaquely downstream).
• Tests: tests/test_modeler.py (new) covers every Grid path (single/multi-band, float/int/string dtypes, nodata→null, UCUM unit resolution, synthesized bands, projected CRS, single-cell axis midpoint, and the two guards), all validated against the vendored OGC CoverageJSON schema; plus new CoverageInput validation/synthesis tests in tests/test_input.py.
• Docs — docs/01,04,05,06 updated to reflect the function-based modeler, the construction-time band resolution, and the Polygon-blocker correction (covjson-pydantic 0.8.0 ships the Polygon domain types).

Key design decisions

• Functions, not a class: the conversion is stateless; if configuration is ever needed (e.g., a TiledNdArray threshold), introduce a config argument then.
• bands resolved once, at construction: CoverageInput is the post-resolution representation; precedence/enrichment stays upstream in the converters. Rationale captured in docs/04 section 3.
• Grid axes: x west-east, y north-south (raster row 0 is north); a single-cell axis collapses to its bounds midpoint (CompactAxis requires start == stop when num == 1).
• Multi-domain support deferred: Point/PointSeries (Modeler part 2: per-domain input union + Point/PointSeries + CoverageCollection #18), Trajectory (Modeler part 3: Trajectory domain #19), and Polygon/PolygonSeries (Modeler part 4: Polygon / PolygonSeries domain #20) arrive via the per-domain input union (docs/04 section 7), introduced when the second domain type lands.

[emmanuelmathot]

Nice work, Chuck — clean, well-documented, and the test coverage is excellent. Approving. Left two minor notes: one half-pixel CompactAxis question worth a tracking issue, and a small nit. Neither blocks merge.

[emmanuelmathot]

🟨 Reviewer-found (not from the original design notes).

CompactAxis uses the bounds edges as start/stop, not cell centers.

For num > 1 the axis is built as start=west, stop=east, num=width, so the generated coordinates are the outer bounds edges. In CoverageJSON a CompactAxis describes the coordinate values at which cells are defined (the cell centers), so this is off by half a pixel — e.g. 2 columns over -10..10 yields coords -10 and 10, but the actual cell centers are -5 and +5.

It is also inconsistent with the num == 1 path in _compact_axis, which does collapse to the midpoint (a true center).

The inline comment already flags this ("pixel-center offsets are a possible later refinement"), so I am fine deferring the fix in this PR — but could you please open a tracking issue so the half-pixel offset is not lost? Suggested scope: shift start/stop to cell centers (west + dx/2 … east - dx/2) and add a roundtrip test asserting cell-center coordinates. Reference this thread from the issue.

[chuckwondo]

Good catch. I thought I had caught that, but I must be think of something else I was working on with a compact axis (perhaps my own experimenting elsewhere).

[emmanuelmathot]

🟨 Reviewer-found.

nit: 0 in self.data.shape also matches shape[0] == 0, already rejected above with a different message — so a (0, h, w) array reports "must be 2-D or 3-D" instead of "non-empty". Harmless; could narrow to data.shape[-2:] for a consistent message.

[chuckwondo]

This proposed change does not change the error a user sees, and actually makes the code harder to reason about because the slicing causes the reader to pause to grok the reason for the slicing, which is merely to avoid a potentially redundant check of shape[0] against 0. That's additional cognitive load that's not worth merely skipping an unnecessary check of a single element in the shape tuple for no change in behavior.

[chuckwondo]

Thanks @emmanuelmathot. I skipped the nit, but addressed the cell-centered compact axis suggestion. I preferred to keep it in this PR (not much to change) rather than splitting the logic to a separate tracking PR.