geotiff: drop attrs['crs'] on rotated reads (#2122)

[brendancol]

Summary

Closes #2122.

• _populate_attrs_from_geo_info now drops attrs['crs'] and attrs['crs_wkt'] on rotated reads opened with allow_rotated=True, matching the public docstring contract. The gate keys on geo_info.transform.rotated_affine (set by the geotag parser when a rotated ModelTransformationTag is consumed under the opt-in), so general no-georef reads still surface CRS attrs when the file has one declared but no transform tags.
• VRT eager and chunked backends gain the same gate, keyed on the GDAL GeoTransform's b / d rotation terms.
• Updated docs/source/user_guide/attrs_contract.rst and the _attrs.py module docstring to reflect the rotated-read exception.

Backend coverage

Backend	Status
numpy (eager)	covered + tested
dask	covered + tested
cupy	xfail in the test until the GPU CPU-fallback path forwards allow_rotated (sibling finding tracked separately)
dask + cupy	covered + tested (routes through the dask path)
VRT eager	covered + tested
VRT chunked	covered + tested

Test plan

• pytest xrspatial/geotiff/tests/test_allow_rotated_no_crs_2122.py: 7 pass + 1 xfail.
• pytest xrspatial/geotiff/tests/ -k "not gpu and not cuda": 3511 pass, 17 skipped, 1 xfailed (no regressions).
• Reproduction in the issue now yields da.attrs.get('crs') is None and 'crs_wkt' not in da.attrs.
• Axis-aligned reads still emit crs / crs_wkt / transform.
• to_geotiff(arr, path, crs=32610) (no coords) still round-trips the CRS through a read.

[brendancol]

PR Review: geotiff: drop attrs['crs'] on rotated reads (#2122)

The fix closes the documented gap where attrs['crs'] and attrs['crs_wkt'] leaked through on rotated reads opened with allow_rotated=True. Test coverage on the four GeoTIFF backends plus both VRT entry points is good. One internal-consistency gap and a couple of smaller items below.

Blockers (must fix before merge)

None

Suggestions (should fix, not blocking)

• xrspatial/geotiff/_backends/vrt.py:264-268, 727-731: on rotated VRT reads under allow_rotated=True, the coords path keeps calling _coords_from_pixel_geometry with the default has_georef=True, so the returned DataArray carries float projected coords computed from the axis-aligned interpretation of the rotated transform. The eager GeoTIFF path emits integer pixel coords for the same case. I verified empirically: open_geotiff(rotated.vrt, allow_rotated=True).coords['x'].dtype is float64 with values [0.5, 1.5, 2.5, 3.5], while the eager GeoTIFF path returns int64 [0, 1, 2, 3]. The attrs_contract.rst text the PR adds says "the in-memory array is a pixel grid with integer coords"; the VRT path violates that. Pass has_georef=False (or equivalent) through _coords_from_pixel_geometry when _vrt_is_rotated so both paths produce the same shape.
• xrspatial/geotiff/_backends/vrt.py:283, 739: when the VRT is rotated, neither the eager nor chunked path stamps attrs[_NO_GEOREF_KEY] = True. The eager GeoTIFF path stamps the marker via _populate_attrs_from_geo_info whenever has_georef=False, including the rotated case. Downstream code that branches on the marker (writer round-trip detection in _coords.py:54, test_no_georef_writer_round_trip_1949.py) treats a rotated-read DataArray differently depending on which backend produced it. Stamping _NO_GEOREF_KEY on the rotated VRT branch would close the gap.
• xrspatial/geotiff/tests/test_allow_rotated_no_crs_2122.py:285-312: the VRT rotated tests check that crs, crs_wkt, transform are absent but do not check coords['x'].dtype or the _NO_GEOREF_KEY stamp. The GeoTIFF tests (lines 137-139, 154-155) do check coord dtype. Adding the coord-dtype and marker assertions on the VRT tests would pin the contract symmetrically across backends and catch the consistency gap above.

Nits (optional improvements)

• xrspatial/geotiff/_backends/vrt.py:293-295, 721-723: _vrt_is_rotated is computed via gt[2] != 0.0 or gt[4] != 0.0, exact float comparison. The GeoTIFF geotag parser at _geotags.py:671-675 uses a scaled tolerance (1e-12 * scale) to absorb floating-point noise from ModelTransformation tags. The existing rotation validator in _validation.py:886 already uses exact == 0.0, so the PR is consistent with current VRT policy, but a noise term like 1e-16 from XML round-tripping would now trigger the no-georef branch on VRT while the GeoTIFF side would absorb it. Worth tracking, not worth blocking.
• xrspatial/geotiff/_backends/vrt.py:284-295, 714-723: the _vrt_is_rotated block and the comment that explains it are duplicated verbatim across the eager and chunked branches. A small private helper (e.g. _gt_is_rotated(gt) next to _gdal_geotransform_to_affine_tuple) would let both sites share one definition. Cosmetic only.
• xrspatial/geotiff/tests/test_allow_rotated_no_crs_2122.py:166-184: xfail(strict=True, raises=NotImplementedError) is the right call for the GPU sibling-finding, but the test name test_cupy_rotated_read_drops_crs reads as a positive assertion. Renaming to something like test_cupy_rotated_read_drops_crs_xfail_gpu_fallback would make the intent obvious in CI output.

What looks good

• The gate keys on geo_info.transform.rotated_affine rather than the bare has_georef flag, so the writer's crs= kwarg path (general no-georef, axis-aligned) still surfaces crs and crs_wkt. The inline comment at _attrs.py:371-380 is clear about that distinction.
• Docs and module docstring both updated to match the new contract. Round-trip stability for the writer's crs= kwarg is exercised by an explicit regression test (test_axis_aligned_read_still_emits_crs).
• The dask+CuPy test case correctly notes that the dask path forwards allow_rotated and bypasses the eager GPU CPU-fallback.
• Tifffile import migrated to pytest.importorskip so the fast lane is not broken.

Checklist

• Correctness: gate logic correct on the non-VRT path
• Backend completeness: VRT eager + chunked drop attrs but emit projected float coords (Suggestion 1)
• Float/NaN handling: untouched
• Edge cases: axis-aligned regression covered; writer crs= kwarg case covered
• Dask path: covered + tested
• CuPy path: xfail with strict raises gate
• Tests use unique tmp paths
• Reference values asserted, not just "doesn't crash"
• VRT tests do not assert coord dtype / no-georef marker (Suggestion 3)
• Public docstring + contract doc updated
• No premature .values / .compute() in the new code

[brendancol]

Review follow-up

Pushed ab85158 to address all three suggestions:

• VRT eager + chunked rotated reads now pass has_georef=False into _coords_from_pixel_geometry, so da.x.dtype == da.y.dtype == np.int64. Matches the eager non-VRT path.
• VRT eager + chunked rotated branches now stamp attrs[_NO_GEOREF_KEY] = True. Aligns with _attrs.py:414 and the no-transform arm.
• test_vrt_eager_rotated_read_drops_crs and test_vrt_chunked_rotated_read_drops_crs now assert the int64 coord dtype and the _NO_GEOREF_KEY marker, so the parity gap is pinned.

Full geotiff suite still passes locally (664 / 1 xfailed). Waiting on CI.