flood_depth and curve_number_runoff return float32 on dask backends for float32 input

[brendancol]

Describe the bug

flood_depth and curve_number_runoff document a float64 output, and the numpy and cupy backends cast the input to float64. The dask and dask+cupy backends skip that cast, so a float32 input raster comes back as float32. The same call returns a different dtype depending on the backend.

Steps to reproduce

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

a = np.array([[0., 2.], [5., 1.]], dtype=np.float32)
numpy_in = xr.DataArray(a, dims=('y', 'x'))
dask_in = xr.DataArray(da.from_array(a, chunks=(2, 2)), dims=('y', 'x'))

print(flood_depth(numpy_in, 5.0).dtype)        # float64
print(flood_depth(dask_in, 5.0).data.dtype)    # float32

Observed dtypes for a float32 input:

function	numpy	cupy	dask	dask+cupy
flood_depth	float64	float64	float32	float32
curve_number_runoff	float64	float64	float32	float32

Expected behavior

All four backends return float64, matching the docstring ("2D float64 grid").

Root cause

_flood_depth_numpy and _cn_runoff_numpy call np.asarray(..., dtype=np.float64), and the cupy helpers cast to cp.float64. The dask helpers _flood_depth_dask and _cn_runoff_dask operate on the input array with no cast, so float32 propagates through. The dask+cupy wrappers reuse the dask helper, so they inherit the same dtype.

The other flood functions are not affected: travel_time and flood_depth_vegetation upcast through the float64 _TAN_MIN clamp, inundation through the 1.0/0.0 literals, and vegetation_roughness through np.interp.

The existing cross-backend tests only use float64 inputs, so this divergence is not currently covered.

Found by

/sweep-accuracy (category 5: backend inconsistency).