proximity/allocation/direction: output dtype and .name differ across backends

[brendancol]

Describe the bug

proximity, allocation, and direction in xrspatial/proximity.py return different output metadata depending on the array backend. Two mismatches:

1. Output dtype depends on the backend. With a finite max_distance, the dask+numpy path returns a DataArray whose declared dtype is float64, while numpy, cupy, dask+cupy, and the unbounded dask+numpy KDTree path all return float32. The dask chunk function actually produces float32 data, so the float64 label is wrong both against the real data and against every other backend. All three functions document dtype=float32 in their examples. The cause is in _process_dask: it calls da.map_overlap(..., meta=np.array(())), and that empty array defaults to float64.

2. .name leaks an internal dask token. On dask backends the returned DataArray's .name comes out as a dask op name like _trim-<hash>, _kdtree_chunk_fn-<hash>, or asarray-<hash>. On numpy and cupy it's None. Downstream code that keys on .name or serializes it gets backend-dependent junk.

Expected behavior

For a given input, all four backends (numpy, cupy, dask+numpy, dask+cupy) should return the same dtype (float32) and the same .name, for both bounded and unbounded max_distance. attrs, coords, and dims are already preserved consistently and should stay that way.

Additional context

Found during a metadata-propagation audit of the proximity module. The computed values are correct; only the declared metadata is wrong, so this only bites downstream code that inspects dtype or name rather than the array values.