Accept target_values=None in surface_distance trio (#3712)

[shaikn6]

Fixes #3712

Proposed Changes

• surface_distance, surface_allocation, surface_direction now accept target_values=None (the value wrapper code passes when its own optional arg is unset), matching proximity / allocation / direction / cost_distance.
• Changed the three signatures from target_values: list = [] to target_values: list = None and added the sibling if target_values is None: target_values = [] guard in the shared _compute dispatcher.
• Added a regression test (test_target_values_none_matches_empty) parametrized over all three functions.

Why / evidence

The proximity trio and cost_distance all declare target_values: list = None and normalize to [] in the body. The three surface_* functions declared target_values: list = [] with no None guard, so target_values=None fell through to np.asarray(None, dtype=np.float64) (a 0-d array) and blew up before the numba kernel. On numpy 2.3 it surfaces as the existing ValueError: target_values must be a 1-D sequence; the issue reports a ~40-line numba TypingError on older numpy. Either way it is broken. [] as a default is also the mutable-default anti-pattern the siblings already avoid.

Confirmed with the reproduction from #3712 on this checkout: pre-fix, surface_distance/allocation/direction(target_values=None) raise while the other four return normally; post-fix all seven succeed.

Change

[] and None both mean "treat every non-zero finite pixel as a source", so callers passing an explicit list are unaffected and callers passing None go from a traceback to working code. No parameter renamed, no accepted input changes meaning, so no deprecation shim is needed.

Note: balanced_allocation carries the same target_values: list = [] default (flagged in #3712 as out of scope) and is left untouched here.

Verified

$ python -m pytest xrspatial/tests/test_surface_distance.py -q
81 passed, 19 skipped

$ python -m pytest xrspatial/tests/test_surface_distance.py -q -k target_values
6 passed, 94 deselected

$ python repro_3712.py   # reproduction script from the issue
proximity(target_values=None) -> OK
allocation(target_values=None) -> OK
direction(target_values=None) -> OK
cost_distance(target_values=None) -> OK
surface_distance(target_values=None) -> OK
surface_allocation(target_values=None) -> OK
surface_direction(target_values=None) -> OK

flake8 / isort: no new violations introduced by this change (the pre-existing surface_distance.py isort drift is tracked separately in #3710).

[brendancol]

@shaikn6 Hey hey, what did you think of earlier PR here: #3718

Can you help me understand what is different about this PR. Thanks!

[shaikn6]

Thanks for flagging — on comparing, #3746 is functionally the same fix as #3718 (same three signatures, same _compute normalization), so I should have checked for an existing PR on #3712 first. The only addition is a regression test parametrized over all three functions (test_target_values_none_matches_empty); feel free to lift it into #3718. Closing this one in favor of yours.

[brendancol]

@shaikn6 cool cool, thanks for the contribution. I could help guide you a bit to other areas if youre interested in other contributions. Any existing tools (or new tools) you'd be interested in working on?

[shaikn6]

Appreciate it — yes, interested. I've mostly been running /sweep-api-consistency-style passes looking for signature/behavior drift within a module, but I'd rather point that at something you actually need than keep freelancing. What's open — a specific tool that needs work, or an area (e.g. more of the proximity/surface_distance family, a different module entirely) you'd want eyes on first?