merge() lacks transform_precision parameter exposed by reproject()

[brendancol]

Summary

xrspatial.reproject.merge() is missing the transform_precision parameter that reproject() exposes. Both functions perform the same family of coordinate-transform work, so users currently have no way to control control-grid subdivisions when merging, or to request exact per-pixel pyproj transforms.

Where the drift lives

In xrspatial/reproject/__init__.py:

• reproject() accepts transform_precision=16 (around line 471) and documents it as the control-grid subdivision count, with 0 meaning exact per-pixel transforms.
• merge() does not accept it (around line 1333).
• _merge_inmemory hardcodes 16 when calling _reproject_chunk_numpy (around line 1594).
• _merge_dask binds precision=16 into the per-block adapter via functools.partial (around line 1699).
• The existing _validate_grid_params call inside merge() already accepts a transform_precision argument; it is currently passed None.

Fix scope

• Add transform_precision=16 to the merge() signature (after chunk_size).
• Pass it to _validate_grid_params instead of None.
• Plumb it through _merge_inmemory and _merge_dask so the per-tile reproject calls use the user value rather than the hardcoded 16.
• Update the merge() docstring with the parameter description, adapted from reproject().

What this issue intentionally does not change

reproject() also exposes max_memory, which is consumed only by the streaming reprojection path. merge() has no streaming path, so adding max_memory there would be misleading. The docstring will get a one-line note that the dask path should be used for very large outputs (which merge() already auto-promotes to).