geotiff: GPU stripped windowed coords honour has_georef=False (#1753)

The GPU stripped fallback path in read_geotiff_gpu (added in PR #1738
so the GPU path forwards max_pixels / window / band to the CPU helper)
returned float64 coords synthesised from the default unit GeoTransform
for non-georef windowed reads, while the eager numpy, dask, and tiled
GPU paths all returned integer pixel coords. The pre-fix output
``y=[-0.5, -1.5, ...]`` regressed the #1710 fix on the stripped GPU
fallback only.

The branch at __init__.py 2724-2747 only guarded ``t is None``, which
is unreachable because _extract_transform always returns a default
GeoTransform() instance with has_georef=False. The default transform
has pixel_width=1.0, pixel_height=-1.0, so the PixelIsArea sub-branch
synthesised the half-pixel-shifted negative-y output instead of
falling through to the integer-coord shortcut. dask+cupy stripped
windowed reads shared the same code path so the bug fired there too.

Fix: route ``not getattr(geo_info, 'has_georef', True)`` through the
integer-coord branch alongside the existing ``t is None`` check.
Mirror the eager numpy ``open_geotiff`` body at __init__.py:834-836
and the dask path at read_geotiff_dask which both already check
has_georef. Also corrected the latent off-by-one in the integer-coord
branch (was arange(r1-r0); should be arange(r0, r1) so an offset
window like (2,3,6,7) returns [2,3,4,5]/[3,4,5,6] not [0,1,2,3]).

14 regression tests in test_gpu_stripped_no_georef_window_1753.py:
- TestStrippedGpuWindowedNoGeoref: origin window, offset window,
  dask+cupy variants of both, uint16 dtype, no transform attr
- TestStrippedGpuWindowedBackendParity: dtype-parity (3 windows) and
  value-parity (3 windows) across eager / dask / GPU / dask+cupy
- TestStrippedGpuWindowedGeorefStillWorks: PixelIsArea origin and
  offset windows still get float64 coords with the correct half-pixel
  shift (regression guard against the fix mis-firing on georef files)

All 2005 non-stale geotiff tests still pass. 10 pre-existing failures
in test_predictor2_big_endian_gpu_1517.py are stale test infrastructure
from PR #1708 (which renamed read_to_array to _read_to_array in the
public module namespace) and unrelated to this fix.

Categories: Cat 3 (off-by-one boundary handling, latent on the
previously unreachable branch) + Cat 5 (backend inconsistency:
CPU eager and dask returned int64 integer coords while stripped GPU
returned float64 half-pixel-shifted coords on the same file).

Closes #1753

Author: brendancol