Fix invalid z_unit error to list accepted unit names

[brendancol]

Closes #2858

What changed

• The geodesic z_unit check in aspect() and slope() built its error message from sorted(set(Z_UNITS.values())), which are the numeric conversion factors (0.3048, 1.0, 1000.0, 1609.344), not the unit names a user can pass. It now reports sorted(Z_UNITS) so the message lists the accepted unit names.
• Fixed in both aspect.py and slope.py since they share the same check and message format.

Before:

z_unit must be one of [0.3048, 1.0, 1000.0, 1609.344], got 'cubit'

After:

z_unit must be one of ['feet', 'foot', 'ft', 'kilometer', 'kilometers', 'km', 'm', 'meter', 'meters', 'mi', 'mile', 'miles'], got 'cubit'

Backend coverage

This is a validation-path change that runs before any backend dispatch, so it applies to all four backends (numpy / cupy / dask+numpy / dask+cupy).

Test plan

• Extended test_invalid_z_unit_raises in test_geodesic_aspect.py and test_geodesic_slope.py to assert the message contains the accepted unit names and not bare numeric factors.
• pytest passes for both updated tests.

[brendancol]

PR Review: Fix invalid z_unit error to list accepted unit names

Blockers (must fix before merge)

None.

Suggestions (should fix, not blocking)

None.

Nits (optional improvements)

• The test guards against the old factors by name (assert "0.3048" not in msg). That works. A stricter version would reject any bare float, e.g. assert not re.search(r"\b\d+\.\d+", msg), so a future regression that swaps in different factors still trips it. Optional; the current asserts already fail against the old code.

What looks good

• Root cause is right. Z_UNITS keys are the unit names users pass; the values are numeric factors. sorted(Z_UNITS) reports the keys, which is what the message should say.
• The same bug was in aspect.py:448 and slope.py:415. Fixing both keeps the two messages in sync.
• sorted(Z_UNITS) sorts the keys lexically, so the message order is stable across runs.
• This runs in the validation path before backend dispatch, so there's no numpy/cupy/dask/dask-cupy parity question.
• Tests check both the presence of accepted names and the absence of the old factors, and they pass.

Checklist

• Algorithm matches reference: n/a (error-message fix)
• All implemented backends consistent: n/a (pre-dispatch validation)
• NaN handling correct: n/a
• Edge cases covered by tests: yes (invalid unit string)
• Dask chunk boundaries handled: n/a
• No premature materialization: n/a
• Benchmark exists or not needed: not needed
• README feature matrix updated: not needed (no API change)
• Docstrings present and accurate: unchanged

[brendancol]

Follow-up review (after nit fix)

The earlier nit is addressed: both test_invalid_z_unit_raises tests now assert not re.search(r"\d+\.\d+", msg), so any bare decimal in the message fails the test rather than just the two old factors. import re was added to both test files. Tests pass.

No new blockers, suggestions, or nits. The remaining F841 flake8 warning on the unused flat variable in test_geodesic_aspect.py predates this PR and sits outside the changed lines, so it is left alone.