Make binary() output float32 on all backends

[brendancol]

Summary

binary() returned the input dtype on the numpy and dask+numpy backends but always float32 on cupy and dask+cupy. This allocates float32 in _cpu_binary so the result dtype matches across all four backends, which is what the cupy path and every other classifier already do.

Why

_cpu_binary allocated np.empty(data.shape, dtype=data.dtype). For a float64 input the numpy and dask results were float64 while the cupy results were float32. Integer input was worse: the array cannot store the NaN that binary writes for non-finite cells.

Changes

• _cpu_binary allocates a float32 output.
• Added test_binary_output_dtype_float32 and test_binary_dask_output_dtype_float32.

Testing

• pytest xrspatial/tests/test_classify.py passes (104 tests, numpy/dask/cupy/dask+cupy).

Closes #3511.

[brendancol]

PR Review: Make binary() output float32 on all backends

Blockers

None.

Suggestions

• The four existing backend tests (test_binary_numpy, test_binary_dask_numpy, test_binary_cupy, test_binary_dask_cupy in xrspatial/tests/test_classify.py) call general_output_checks without verify_dtype=True. The two new tests assert float32 only on numpy and dask+numpy, so the cupy and dask+cupy output dtype is not checked anywhere. Passing verify_dtype=True to those four tests locks the float32 contract on all four backends without adding new test functions, which is what the reclassify tests already do.

Nits

• The new comment says the input dtype "could not hold the NaN sentinel for integer input." That holds in principle, but an integer raster has no non-finite cells, so binary never actually wrote NaN into an int output. The cross-backend consistency point alone justifies the change.
• test_binary_dask_output_dtype_float32 uses one chunk layout. Output dtype is chunk-independent here, so a second layout adds little.

What looks good

• One-line change plus a comment. Values are unchanged, only the output dtype.
• Brings numpy/dask in line with the cupy 'f4' allocation and with the docstring example, which already prints dtype=float32 (classify.py line 161).
• Regression tests cover numpy (three input dtypes) and dask.
• Full classify suite passes: 104 tests across numpy, dask, cupy, dask+cupy.

Duplicate

PR #3513 (metadata sweep) fixes the same binary() dtype bug. I am not merging or closing either here; flagging for maintainer reconciliation. This PR keeps its fix self-consistent.

Checklist

• Classification logic untouched (dtype-only change)
• Backends produce consistent dtype
• NaN handling correct
• Edge cases: integer/float32/float64 input covered
• Dask chunk boundaries: dtype is chunk-independent
• No premature materialization or copies
• No benchmark needed (dtype-only)
• Docstring documents float32