stable_only=True enforced after bbox metadata read on remote/VRT sources

[brendancol]

Describe the bug

open_geotiff(..., bbox=...) resolves the bounding box to a pixel window before it runs the stable_only=True rejection for remote and VRT sources. The bbox resolver reads source geo metadata first. The TIFF path reads a header (a range GET for an HTTP/fsspec source); the VRT path parses the VRT XML. Both stable-only gates only fire after that, so a stable_only=True request can trigger remote metadata I/O or a VRT parse before it gets refused.

In xrspatial/geotiff/__init__.py, the bbox-to-window resolution sits ahead of the _validate_stable_only_remote call and ahead of the VRT dispatch into read_vrt (which holds the VRT stable-only gate). The docstring on _validate_stable_only_remote in xrspatial/geotiff/_validation.py states the remote rejection must happen before any range GET or decode work. The bbox path breaks that ordering.

Expected behavior

With stable_only=True and no allow_experimental_codecs:

• A remote (HTTP / fsspec) source raises RemoteStableSourcesOnlyError before any bbox metadata read.
• A .vrt source raises VRTStableSourcesOnlyError before the VRT XML is parsed for the bbox.

Passing bbox= should not change whether or when the rejection happens.

Affected combinations (currently uncovered)

• open_geotiff(remote, bbox=..., stable_only=True)
• open_geotiff(remote_vrt, bbox=..., stable_only=True)

Fix

Move the remote and VRT stable-only checks ahead of bbox resolution: after source classification and dispatcher kwarg validation, but before any geo-metadata read or VRT parse that bbox handling triggers.

Additional context

Part of the GeoTIFF release gate work tracked under epic #2342.