Gate CUDA reproject fast path on WGS84-compatible datums (#3094)

[brendancol]

Closes #3094

• Adds the non-WGS84 datum guard from reproject: numba fast path corrupts coordinates for non-WGS84 datums #2651 to try_cuda_transform. The CUDA dispatcher matched projected CRSs whose datum sits in the Helmert table (OSGB36, DHDN, MGI, ED50, NAD27), then projected them with WGS84 constants and no datum shift, putting cupy and dask+cupy results ~100 m off while numpy went through pyproj. With the guard, those pairs return None and the chunk worker falls back to the CPU path.
• Adds TestNonWgsDatumCudaFastPath: bail-out checks for EPSG:27700 (both directions) and NAD27, a check that the WGS84 UTM fast path stays active, and an end-to-end numpy-vs-cupy parity test for a 4326 -> 27700 reproject (NaN masks equal, values within 1e-4).
• Also carries the accuracy-sweep state CSV update for the reproject module.

Backend coverage: numpy and dask+numpy were already correct; this fixes cupy and dask+cupy.

Test plan:

• pytest xrspatial/tests/test_reproject.py -k NonWgsDatum (10 passed, CPU + CUDA classes, run on a GPU host)
• pytest xrspatial/tests/test_reproject.py -k "cupy or cuda or CuPy" (48 passed on a GPU host)
• Verified pre-fix divergence: try_cuda_transform coordinates off by ~96 m vs pyproj; end-to-end cupy vs numpy max diff 0.094 on [0,1] data

[brendancol]

PR Review: Gate CUDA reproject fast path on WGS84-compatible datums (#3094)

Blockers (must fix before merge)

None found.

Suggestions (should fix, not blocking)

None.

Nits (optional improvements)

• _get_datum_params runs crs.to_dict() (which goes through pyproj's to_proj4) twice per chunk now that the guard sits in try_cuda_transform (xrspatial/reproject/_projections_cuda.py:751). The CPU fast path pays the same per-chunk cost in try_numba_transform, so this is parity rather than a regression. If chunk-loop profiling ever shows it, a small memo cache keyed on the CRS would fix both paths at once. Not needed for this PR.

What looks good

• The guard is a faithful mirror of the #2651 CPU fix and sits before the cupy array allocation, so bailed pairs don't pay for device buffers they never use.
• Root cause is correctly identified: the projected-CRS matchers (_tmerc_params, _lcc_params, ...) accept any datum in the Helmert table via _is_wgs84_compatible_ellipsoid, so EPSG:27700 reached the WGS84 Krueger kernels. The guard cuts that off for every affected datum (OSGB36, DHDN, MGI, ED50, NAD27, ...) rather than special-casing one code.
• Test coverage is the right shape: both directions for 27700, the NAD27 geographic case, a WGS84-UTM check that proves the fast path is not over-blocked, and an end-to-end numpy-vs-cupy parity test with exact NaN-mask agreement. The parity test would have caught the original bug (~0.094 value error on [0,1] data).
• Post-guard, the cupy worker falls back to the CPU coordinate path, which already defers these pairs to pyproj, so all four backends now agree by construction.

Checklist

• Algorithm matches reference (#2651 CPU guard)
• All implemented backends produce consistent results (numpy-vs-cupy parity test, run on a GPU host)
• NaN handling is correct (mask equality asserted)
• Edge cases are covered by tests (both directions, geographic + projected non-WGS84 sides, fast-path-still-active)
• Dask chunk boundaries handled correctly (guard is per-chunk, no shape changes)
• No premature materialization or unnecessary copies (guard placed before allocation)
• Benchmark not needed (correctness fix; affected pairs previously returned wrong data)
• README feature matrix unchanged (no API or backend-support change)
• Docstrings/comments explain the why, with issue references