Epic: GeoTIFF release documentation and readiness checklist

[brendancol]

Goal

Make the GeoTIFF release understandable and auditable by treating documentation, release notes, and a release checklist as first-class deliverables.

The module has many nuanced paths. For release readiness, undocumented behavior is effectively a bug because users cannot tell what is safe to rely on.

Required Documentation

• GeoTIFF feature tier table.
• Stable/advanced/experimental/internal-only definitions.
• Supported codecs and codec caveats.
• COG read/write support and limits.
• VRT supported subset and non-goals.
• Nodata lifecycle behavior.
• CRS/WKT behavior and fail-closed defaults.
• Rotated/sheared transform behavior.
• Remote read safety limits and environment variables.
• GPU support status as experimental.
• Known unsupported combinations.

Release Checklist

Create a checklist that must pass before the GeoTIFF-focused release:

• Local GeoTIFF read/write gate passes.
• COG read/write gate passes.
• Windowed read transform/coords gate passes.
• Nodata lifecycle gate passes.
• CRS/WKT fail-closed gate passes.
• Dask parity gate passes for promised paths.
• VRT simple mosaic gate passes.
• HTTP/fsspec bounded-read gate passes.
• External overview sidecar metadata parity gate passes.
• Unsupported/ambiguous metadata negative tests pass.
• GPU experimental smoke tests are either passing or clearly skipped with documented requirements.
• Docs and docstrings match SUPPORTED_FEATURES and release notes.

Work Items

• Add or update docs/source/reference/geotiff.rst with release contract sections.
• Add/update user guide material for safe GeoTIFF IO usage.
• Add a release checklist document under docs or project release docs.
• Audit examples/notebooks so they do not imply unsupported behavior is stable.
• Add release-note draft bullets for the GeoTIFF module.
• Link relevant epics/issues from the release checklist.

Acceptance Criteria

• A maintainer can decide whether the GeoTIFF module is release-ready from the checklist.
• Users can distinguish stable from advanced/experimental behavior without reading source code.
• Docs do not promise full GDAL/VRT/GPU/codec parity where it is not guaranteed.
• Release notes accurately reflect the final support contract.