geotiff: reader kwarg order drift across open_geotiff/read_geotiff_gpu/read_geotiff_dask/read_vrt

[brendancol]

The four public reader entry points expose name, chunks, window, overview_level in different orders. The kwargs are keyword-only so positional callers never broke, but inspect.signature, IDE autocomplete, and the Sphinx-rendered docs all show drift.

Current order after source (keyword-only):

function	order
open_geotiff	dtype, window, overview_level, band, name, chunks, gpu, max_pixels, on_gpu_failure, missing_sources
read_geotiff_gpu	dtype, overview_level, window, band, name, chunks, max_pixels, on_gpu_failure, gpu
read_geotiff_dask	dtype, chunks, overview_level, window, band, max_pixels, name
read_vrt	dtype, window, band, name, chunks, gpu, max_pixels, missing_sources

read_vrt already matches open_geotiff (modulo params it does not accept). read_geotiff_gpu has overview_level and window swapped. read_geotiff_dask has chunks and name out of order.

This mirrors the writer-side fix in #1922 / #1925: pick the canonical order (open_geotiff) and reorder the outliers. Add a regression test that pins the keyword-only parameter order for all four readers via inspect.signature.

Scope:

• xrspatial/geotiff/_backends/gpu.py: read_geotiff_gpu
• xrspatial/geotiff/_backends/dask.py: read_geotiff_dask
• xrspatial/geotiff/_backends/vrt.py: read_vrt (already conforms; covered by the regression test)
• New test under xrspatial/geotiff/tests/