reproject: numba fast path corrupts coordinates for non-WGS84 datums

[brendancol]

Describe the bug

The Numba JIT fast path in xrspatial/reproject/_projections.py can silently corrupt output coordinates when either the source or target CRS uses a non-WGS84 datum.

The inner try_numba_transform computes both src_datum and tgt_datum, but the datum-shift wrapper only handles src_datum. Two problems follow:

1. The wrapper applies a geocentric Helmert datum shift to the returned source coordinates as if they were always lon/lat in degrees. For a projected source CRS (OSGB36 / British National Grid, EPSG:27700), those coordinates are easting/northing in metres, not degrees. Shifting metres as if they were degrees gives nonsense.
2. A non-WGS84 target datum is never handled, so the projection kernels (which assume WGS84) skip the target-side datum shift entirely.

Reproduction: reprojecting EPSG:27700 to EPSG:4326 through the numba fast path returns an easting of about 5.24 where pyproj returns 408701.56 metres for the same pixel.

Expected behavior

Transforms involving a non-WGS84 datum on either side should match pyproj. Where the numba fast path can't prove it matches pyproj, it should fall back to pyproj instead of returning corrupted coordinates.

Additional context

Affects projected national grids such as OSGB36 (EPSG:27700), DHDN, and MGI, plus any other entry in _DATUM_PARAMS. Found during a code review of the reproject module.