pathfinding: dask-backed outputs adopt the dask graph token as DataArray.name

[brendancol]

a_star_search and multi_stop_search return unnamed DataArrays on the numpy and cupy backends, but on dask and dask+cupy the result's .name is the internal dask graph token. xr.DataArray(...) falls back to getattr(data, 'name', None) when no name is given, and dask arrays carry their task-key prefix there.

Observed on main (2026-07-08):

import numpy as np, xarray as xr
import dask.array as da
from xrspatial import a_star_search
from xrspatial.pathfinding import multi_stop_search

agg = xr.DataArray(np.ones((8, 8)), dims=['y', 'x'], attrs={'res': (1.0, 1.0)})
agg['y'] = np.linspace(7, 0, 8); agg['x'] = np.linspace(0, 7, 8)
agg_dask = agg.copy(); agg_dask.data = da.from_array(agg.data, chunks=(4, 4))

a_star_search(agg, (7.0, 0.0), (0.0, 7.0)).name        # None
a_star_search(agg_dask, (7.0, 0.0), (0.0, 7.0)).name   # 'concatenate-bf94f35e9f109e8253ed25eaf6425599'
multi_stop_search(agg_dask, [(7.0, 0.0), (0.0, 7.0)]).name  # 'array-16f7995fd6d22ee4b08829515ec36e6b'

cupy behaves like numpy (returns None); dask+cupy leaks the token like dask ('asarray-' for multi_stop_search).

The hash ends up anywhere the variable name matters: to_dataset(), netcdf output, plot titles. And it changes on every call, since the token is content-addressed.

This bug class was already fixed in zonal (#2611) and focal (#2733); slope carries the post-construction reset with a comment pointing at those. pathfinding never got the fix.

Fix: reset .name = None after constructing the output DataArray in both functions, so all four backends match, and pin it with a cross-backend test.

Found by the metadata propagation sweep. Not the same issue as #3644, which covers the attrs drop in multi_stop_search.