geotiff: tighten no-georef sentinel for integer coords (#2087)

[brendancol]

Summary

• Tighten the writer's no-georef sentinel from "any integer dtype on either axis" to the exact reader pattern: int64 ascending contiguous-step-1 arange on both axes.
• User-authored integer-coord projected grids like x=[100,101,102], y=[200,199] no longer silently lose their transform. They get a real transform written, or raise NonUniformCoordsError.
• The legitimate no-georef round-trip is preserved. The reader's np.arange(start, stop, dtype=int64) placeholder still matches on both axes, including for windowed reads.

Background

coords_to_transform at xrspatial/geotiff/_coords.py:353 returned None whenever either x or y had an integer dtype. The fail-closed validator at _coords.py:272 mirrored that. The intent was to round-trip the read-side np.arange(N, dtype=int64) placeholder that coords_from_pixel_geometry emits for files with no GeoTIFF transform tags (#1710, #1753, #1949). The dtype check was too broad: any user-authored projected grid with integer-spaced coords matched and lost its georef silently.

Repro from the original report

da = xr.DataArray(
    np.zeros((2, 3), dtype=np.float32),
    coords={'y': np.array([200, 199]), 'x': np.array([100, 101, 102])},
    dims=('y', 'x'),
)
to_geotiff(da, 'out.tif')
out = open_geotiff('out.tif')
# Before: out.coords['x'] == [0, 1, 2], out.attrs['transform'] is None
# After:  out.coords['x'] == [100.0, 101.0, 102.0], transform present

Sentinel logic

Both call sites now route through a single _is_no_georef_sentinel(coord) helper:

coord.dtype == np.int64
  AND len(coord) >= 1
  AND np.array_equal(coord, np.arange(coord[0], coord[0] + len(coord), dtype=int64))

Both axes must match for the no-georef path to fire. Mixed dtypes (one int64-arange, one float), non-int64 int dtypes (int32, int16, uint32), descending coords, non-unit step, and non-uniform spacing all fall through.

Trade-offs

• A user who authors a DataArray whose coords match the reader pattern exactly (int64 ascending step 1 on both axes, no attrs['transform'] set) still gets no-georef treatment. Documented in the helper docstring; the explicit attrs['transform'] escape hatch still works.
• A user who subsamples (da.isel(x=slice(None, None, 2))) or coarsens a no-georef array no longer falls under the sentinel. The resulting step-2 int64 array gets a real transform written. Coord values round-trip exactly; only the dtype flips on subsequent reads.

Backend coverage

All four writer backends (numpy, dask, cupy, dask+cupy) call coords_to_transform and the validator through the same code path. The fix lives in _coords.py so every backend gets it.

Closes #2087.

Test plan

• pytest xrspatial/geotiff/tests/test_int_coord_sentinel_2087.py -- 17 new cases pass
• pytest xrspatial/geotiff/tests/test_no_georef_writer_round_trip_1949.py -- 13 pass; 5 cases that pinned the old over-broad sentinel were updated to the new contract
• pytest xrspatial/geotiff/tests/ -k "coord or georef or transform or roundtrip" -- 513 pass, no new failures