Planar slope() dask backends report float64 dtype but compute float32

[brendancol]

Describe the bug

The planar slope() dask backends declare a float64 lazy dtype, but the computed result is float32. So result.dtype disagrees with what result.compute() returns, and it disagrees with the numpy and cupy backends, which both report float32.

In xrspatial/slope.py, _run_dask_numpy calls map_overlap(..., meta=np.array(())) and _run_dask_cupy calls map_overlap(..., meta=cupy.array(())). Both meta arrays default to float64, but the chunk functions (_cpu, _run_cupy) cast to and return float32, so the advertised lazy dtype is wrong.

The geodesic dask paths already pass meta=np.array((), dtype=np.float32), so they stay consistent. The problem is isolated to the planar paths.

To Reproduce

import numpy as np, xarray as xr
import dask.array as da
from xrspatial import slope

data = np.random.default_rng(0).random((8, 10)) * 100
r = xr.DataArray(data, dims=['y', 'x'], attrs={'res': (30, 30)})
r['y'] = np.linspace(7*30, 0, 8); r['x'] = np.linspace(0, 9*30, 10)
r.data = da.from_array(r.data, chunks=(3, 4))

out = slope(r)
print(out.dtype)                  # float64  (lazy meta)
print(out.data.compute().dtype)   # float32  (actual)

Expected behavior

The lazy dask dtype should match the computed dtype and the numpy/cupy backends: float32.

Impact

Values are correct; only the declared dtype metadata is wrong. A caller that dispatches on or preallocates from the lazy result.dtype sees float64, then gets float32 after compute.

Fix

Pass dtype=np.float32 / dtype=cupy.float32 to the planar dask meta arrays, matching the geodesic paths.

Found by the deep-sweep metadata propagation sweep (Cat 4 dtype semantics / Cat 5 backend-inconsistent metadata).