fire: declare float32 dtype on dask+numpy backend (#3394)

[brendancol]

Closes #3394.

The dask+numpy map_blocks wrappers for six fire functions declared the wrong output dtype: they passed meta=np.array(()) (float64) with no dtype=, so the lazy DataArray reported float64 while the @ngjit kernels return float32. numpy, cupy, and dask+cupy all reported float32, so dask+numpy was the odd one out.

• Pass dtype=np.float32 to _dnbr_dask, _rdnbr_dask, _fli_dask, _fl_dask, _ros_dask, _kbdi_dask. _bsc_dask already passed dtype=np.int8 and is unchanged.
• Add a parametrized regression test asserting the dask+numpy declared dtype (and the computed dtype) matches the numpy backend for every fire function.

Backends: only the dask+numpy declared-dtype metadata changes. Computed values are unaffected on all four backends. The fix matches the existing _bsc_dask pattern.

Test plan:

• pytest xrspatial/tests/test_fire.py (61 passed, includes cupy + dask+cupy on a GPU host)
• Confirmed the 6 new dtype assertions fail before the fix and pass after

[brendancol]

PR Review: fire: declare float32 dtype on dask+numpy backend (#3394)

Blockers (must fix before merge)

None.

Suggestions (should fix, not blocking)

None.

Nits (optional improvements)

• Now that dtype=np.float32 is passed explicitly, the trailing meta=np.array(()) is redundant, since dask uses dtype= as the authoritative declared dtype. Keeping it matches the existing _bsc_dask style, so leaving it is fine. Dropping it would be marginally cleaner but not worth the churn.

What looks good

• The declared dtype now lines up with the kernels' np.full(..., dtype=np.float32) allocation and with the other three backends. I confirmed dtype= drives the lazy declared dtype regardless of the float64 meta.
• The regression test covers all seven fire functions and checks both the lazy declared dtype and the computed dtype against the numpy backend. I ran it with the source change reverted: the six affected cases fail and _bsc_call passes (it was already correct).
• Small, repetitive change: six identical one-line kwarg additions, no algorithm or value change on any backend.

Checklist

• Algorithm matches reference (no algorithm change; metadata only)
• All implemented backends produce consistent results (dtype now uniform float32)
• NaN handling is correct (unchanged)
• Edge cases covered by tests (dtype parity parametrized over every function)
• Dask chunk boundaries handled correctly (element-wise, no overlap)
• No premature materialization or unnecessary copies
• Benchmark not needed (metadata fix)
• README feature matrix not applicable (no new function)
• Docstrings unchanged and still accurate