stable_only=True does not reject HTTP/fsspec sources via direct read_geotiff_gpu()

[brendancol]

Follow-up to #2821 / #2826.

#2821 fixed the eager and dask non-VRT read paths so stable_only=True rejects advanced-tier HTTP/fsspec sources. The fix gates remote sources in open_geotiff (ahead of the eager/dask/GPU dispatch) and adds a direct check in read_geotiff_dask.

The GPU direct entry point read_geotiff_gpu (xrspatial/geotiff/_backends/gpu.py) accepts stable_only but does not gate remote sources on its own. A caller who hits the public open_geotiff(..., gpu=True) path is covered by the shared gate, but read_geotiff_gpu(http_or_fsspec_url, stable_only=True) called directly still slips through, the same gap #2821 closed for the direct dask entry point.

Expected fix: call _validate_stable_only_remote (added in #2826) at the top of read_geotiff_gpu for parity with read_geotiff_dask. Add a GPU-marked test once GPU CI can run it.

Split out from #2821 because it is GPU-only and was out of scope for the eager + dask finding.

[brendancol]

Already implemented on main by #2878 (commit 81ac50a). _read_geotiff_gpu now calls _validate_stable_only_remote before the cupy import and remote fallback, matching read_geotiff_dask. Coverage is in xrspatial/geotiff/tests/test_stable_only_remote_2821.py (the two CPU rejection tests pass; the GPU opt-in test skips cleanly without a device). The issue was just left open after the fix landed. Closing as resolved.