Fix flood dask backends emitting float32 output for float32 input

[brendancol]

Summary

flood_depth() and curve_number_runoff() document a "2D float64 grid" return value. The numpy and cupy backends force float64; the dask and dask+cupy backends ran directly on the input array's dtype, so a float32 input produced a float32 result. The output dtype depended on which backend was active.

import numpy as np, xarray as xr, dask.array as da
from xrspatial.flood import flood_depth
arr = np.array([[0., 1.], [2., 3.]], dtype=np.float32)
mk = lambda d: xr.DataArray(d, dims=('y', 'x'))
flood_depth(mk(arr), 5.0).dtype                 # float64
flood_depth(mk(da.from_array(arr)), 5.0).dtype  # float32 (before this PR)

Fix

Cast the input to float64 in _flood_depth_dask and _cn_runoff_dask, matching the numpy/cupy backends and the documented contract. travel_time() and flood_depth_vegetation() were already float64 on every backend (their _TAN_MIN clamp is an np.float64 scalar that forces promotion) and are untouched.

Tests

Adds float32-input dtype tests for both functions across numpy, cupy, dask, and dask+cupy. Full flood suite passes locally (97 tests, GPU paths included).

Fixes #3496

Found by the metadata-propagation sweep.