reproject: preserve integer dtype in dask+cupy fast path (#2505)

[brendancol]

Closes #2505.

Summary

• _reproject_dask_cupy eager fast path force-allocated the output buffer as cp.float64 regardless of source dtype, so int16/uint8/etc. inputs were silently promoted to float64 while every other backend kept the source dtype.
• Compute out_dtype the same way _reproject_dask does (integer source keeps its dtype, float source stays float64), allocate the result with out_dtype, and clamp+cast each chunk before placement -- mirrors the per-band cast in _reproject_chunk_cupy.
• New TestDaskCupyDtypeParity class with six tests covering int8 / int16 / uint8 / uint16 / float32 plus a direct dask+numpy vs dask+cupy cross-backend dtype check.

Backend coverage

Backend	Before	After
numpy	int16 -> int16	unchanged
dask+numpy	int16 -> int16	unchanged
cupy (eager)	int16 -> int16	unchanged
dask+cupy	int16 -> float64	int16 -> int16

Test plan

• pytest xrspatial/tests/test_reproject.py::TestDaskCupyDtypeParity -- 6 passing
• pytest xrspatial/tests/test_reproject.py -- 351 passing (345 baseline + 6 new)
• New tests fail against pre-fix code, pass against fixed code

[brendancol]

PR Review: reproject: preserve integer dtype in dask+cupy fast path (#2505)

Blockers

None.

Suggestions

None.

Nits

• The new TestDaskCupyDtypeParity tests check result.dtype only. The sibling TestDaskDtypeParity checks both result.data.dtype and result.compute().dtype. Since _reproject_dask_cupy returns an eager cupy ndarray (not a dask array), result.compute() is a no-op so the two forms are equivalent here. Fine as-is; add result.data.dtype if you want exact symmetry with the sibling class.

What looks good

• Same pattern as _reproject_dask (lines 1839-1843) and _reproject_chunk_cupy (lines 609-611, 633). No new patterns introduced.
• Clamp+cast on chunk_data runs at the per-chunk write level, so chunks skipped via continue retain the pre-filled out_dtype nodata.
• The nodata value reaching _reproject_dask_cupy is already integer-compatible when the source is integer (resolved by _detect_nodata(..., dtype=raster.dtype) at line 851), so the cp.full(out_shape, nodata, dtype=int_dtype) allocation can't hit a NaN→int conversion.
• New tests fail on pre-fix code and pass on fixed code (verified by temporarily reverting).
• Six tests covering int8 / int16 / uint8 / uint16 / float32 plus a direct dask+numpy vs dask+cupy parity check.

Checklist

• Pattern matches _reproject_dask and _reproject_chunk_cupy
• All backends now produce consistent dtypes
• NaN handling unchanged
• Edge cases: signed, unsigned, float, skipped chunks
• Dask chunk boundaries unaffected
• No premature materialization
• Benchmark not needed (correctness fix)
• README feature matrix unaffected
• Inline comments reference #2505

[brendancol]

Follow-up review (#2505)

Addressed the nit from the previous review: TestDaskCupyDtypeParity now asserts both result.dtype and result.data.dtype, matching the symmetry used in TestDaskDtypeParity.

No outstanding findings. All 6 new tests still pass.

Disposition of original review:

• Nit (assertion symmetry): fixed in bd45b82.