fire: add Examples sections and backend-support notes to docstrings

[brendancol]

What

Documentation-only change to xrspatial/fire.py. All seven public functions (dnbr, rdnbr, burn_severity_class, fireline_intensity, flame_length, rate_of_spread, kbdi) get:

• A numpydoc Examples section with a runnable numpy example. The printed output was generated by running each example, so it matches the current code.
• A one-line note that the function supports all four backends (NumPy, CuPy, Dask with NumPy, Dask with CuPy), matching the ArrayTypeFunctionMapping dispatch in the module.

Why

A documentation audit found that none of the seven functions had an Examples section, and none documented backend support. Other modules (curvature, proximity, multispectral) carry both. This brings fire in line.

Testing

• xrspatial/tests/test_fire.py: 73 passed
• flake8 xrspatial/fire.py: clean
• Each docstring example was executed; outputs match the documented values.

No behavior changes. Found by the documentation deep-sweep.

[brendancol]

PR Review: fire docstrings (Examples + backend notes)

Doc-only PR. Reviewed on the head branch with the examples re-executed and the backend claims checked against the dispatch table.

Blockers

None.

Suggestions

• The Examples import from the module path (from xrspatial.fire import dnbr) rather than the public top-level export (from xrspatial import dnbr). All seven functions are exported at the package top level, and other docs (curvature, for example) import that way. Switching keeps the copy-paste path aligned with the public API. Applies to all seven examples. I will make this change in this PR.

Nits

• The Examples print exact numpy reprs (e.g. 0.40000004). The repo's .. sourcecode:: python blocks are not run as doctests today (existing ones print dask task-name reprs that could not pass doctest), so there is no CI risk. If doctest coverage is added later, these float reprs may need a refresh. Informational only.

Out of scope (pre-existing, not changing here)

• fireline_intensity documents R as m/s, but rate_of_spread returns m/min. A user chaining the two would pass m/min where m/s is expected. These lines are not touched by this PR and the mismatch predates it. Raising it for a separate decision rather than editing it in a docs-only PR.

What looks good

• Backend claim verified: all seven functions register numpy, cupy, dask, and dask+cupy in ArrayTypeFunctionMapping, so the new "supports all four backends" line is accurate.
• Every Example reproduces its printed output exactly on numpy 2.3.2.
• Returns dtypes (float32, int8) match what the code returns.