Validate viewshed scalar params before dispatch (#2794)

[brendancol]

Closes #2794

What

viewshed() now validates observer_elev and target_elev at the public entry point, before any backend dispatch. NaN, inf, and non-numeric values raise a ValueError that names the offending parameter (e.g. observer_elev must be a finite number, got nan).

The max_distance >= 0 / finite guard already landed on main; this PR adds the matching elevation checks alongside it so all the scalar validation happens up front. The guard style follows the existing max_distance check and the cell-size check in curvature.py.

• Previously NaN/inf elevations fell through into the backend and produced confusing downstream errors instead of a clear message.
• Validation lives before dispatch, so a single guard covers numpy, cupy, dask+numpy, and dask+cupy.

Backends

Entry-point validation, backend-agnostic. Verified on numpy and dask+numpy; cupy/dask+cupy take the same path (no GPU available in this environment).

Test plan

• NaN / inf / -inf / non-numeric observer_elev and target_elev raise ValueError naming the parameter
• dask raster raises up front (confirms before-dispatch behavior)
• finite elevations, including negative, still return a result
• existing max_distance validation tests still pass
• full test_viewshed.py suite passes (103 passed, 1 GPU skip)

[brendancol]

PR Review: Validate viewshed scalar params before dispatch (#2794)

Blockers (must fix before merge)

None.

Suggestions (should fix, not blocking)

None.

Nits (optional improvements)

• xrspatial/viewshed.py (_validate_finite_scalar): the new helper repeats the inline try/except pattern already used for max_distance further down in viewshed(). Not worth refactoring here since max_distance carries an extra >= 0 rule and a different message, but a future cleanup could route max_distance through the same helper plus a range check.

What looks good

• Validation sits at the public entry point before any backend dispatch, so a single guard covers numpy, cupy, dask+numpy, and dask+cupy. The dask test confirms it raises up front rather than from inside the backend.
• The helper rejects NaN, inf, None, lists, and numpy arrays correctly (not np.isfinite(arr) on an array raises, and the except clause catches it). A bool like True passes, which is fine for a numeric scalar.
• Tests cover the rejected values, before-dispatch behavior on a dask raster, and that finite elevations including negative still return a result.
• Docstring updated for both parameters.

Checklist

• NaN handling is correct
• Edge cases covered by tests
• All backends covered (entry-point validation, backend-agnostic)
• No premature materialization
• Benchmark not needed (validation only)
• README not applicable (no new function or backend change)
• Docstrings present and accurate