flood: make mannings_n DataArray validation lazy-safe (#3503)

[brendancol]

Fixes #3503.

Problem

_validate_mannings_n_dataarray in xrspatial/flood.py validated the roughness raster via np.asarray(mannings_n.values). .values materializes the whole array into host memory: a full graph compute for dask, a full device-to-host copy for cupy. This happened during validation, before the lazy result graph was built, so a large mannings_n raster OOMed the client and defeated lazy evaluation in travel_time() and flood_depth_vegetation().

A 2048x2048 dask mannings_n (chunks 512) with a per-block tripwire showed all 16 chunks computed during the travel_time(...) call alone, before any result graph existed.

Fix

Validate without .values:

• dask-backed: skip the eager value check (values cannot be inspected without computing the graph); invalid roughness surfaces as inf/NaN on the lazy path, consistent with the non-DataArray behavior.
• cupy-backed: reduce on device (cp.isfinite(data).all(), (data > 0).all()), transferring only a scalar bool instead of the whole array.
• numpy: unchanged.

Tests

• Existing numpy/cupy/dask/dask+cupy parity and validation tests still pass (90 passed locally, CUDA available).
• New regression tests assert a tripwired dask mannings_n is not materialized during travel_time / flood_depth_vegetation validation.
• Verified the cupy branch end-to-end on GPU: valid roughness stays on device, zero/NaN rejected.

Performance context

• OOM verdict: RISKY before fix (validation materialized large dask/cupy roughness rasters), SAFE after.
• Bottleneck: compute-bound.
• Affected backends: dask+numpy, dask+cupy, cupy. numpy unaffected.
• Found by the performance sweep (Cat 1: dask materialization via .values).