proximity: test gaps for integer rasters, bounded dask+cupy metrics, empty rasters

[brendancol]

Third test-coverage pass over xrspatial/proximity.py (prior passes: #2692). Three gaps remain in xrspatial/tests/test_proximity.py. All three behaviors check out as correct on a CUDA host, so this is test-only work to pin them down.

1. Integer-dtype rasters are never tested. Every raster in the test file is float64, but integer class grids are the main use case for allocation. The bounded dask path calls da.map_overlap(..., boundary=np.nan) on the raw input array, and for an int dtype the NaN pad casts to INT_MIN, which is a non-zero finite "target" value. The only reason halo pixels don't become phantom targets is that the coordinate grids' pads are real NaNs, so the phantom distances come out NaN and never win the nearest-target scan. No test pins that down.

2. Bounded dask+cupy only runs with EUCLIDEAN. _process_dask_cupy sizes its overlap halo using the active distance metric (_halo_depth). Metric-unit mismatches in that sizing are the Dask finite-distance proximity: wrong results on irregular coords and crash on 1xN/Nx1 rasters #2809/Bounded Dask proximity crashes when halo depth exceeds an axis length #2854 bug family, but those regression tests only cover dask+numpy. No test runs a finite max_distance with MANHATTAN or GREAT_CIRCLE through the GPU chunked path.

3. Empty rasters are unpinned. A (0, N) or (N, 0) raster currently fails fast with an IndexError from the coordinate-endpoint lookup. Nothing asserts that it raises instead of returning garbage.

Planned tests for xrspatial/tests/test_proximity.py:

• integer-dtype raster (int32) x {proximity, allocation, direction} x 4 backends x {bounded, unbounded}, compared against the float64 numpy baseline, with float32 output dtype asserted
• bounded dask+cupy x {MANHATTAN, GREAT_CIRCLE} x 3 functions, compared against numpy
• empty raster (0 rows / 0 cols) raises

No source changes.