stable_only docstring overstates the stable-path guarantee for non-VRT sources #2820

Describe the bug

The stable_only docstring for open_geotiff (xrspatial/geotiff/__init__.py:721) says non-VRT sources "already ride the stable reader.local_file path... so the flag is a no-op for them." That is not accurate. The non-VRT read path also accepts HTTP and fsspec sources (_is_http_source / _is_fsspec_uri in _reader.read_to_array), and reader.http / reader.fsspec are marked advanced in SUPPORTED_FEATURES (xrspatial/geotiff/_attrs.py:292-293). So the docstring hides the fact that non-VRT HTTP/fsspec sources are not all on the stable tier.

The same wording is duplicated in the dask backend docstring (xrspatial/geotiff/_backends/dask.py:128).

Expected behavior

The stable_only docstring should describe the contract accurately: stable_only=True restricts reads to the stable-tier local-file path and rejects advanced-tier sources (HTTP/fsspec, VRT). It should not claim the flag is a no-op for all non-VRT sources.

Scope

This is a documentation-only fix. The actual enforcement behavior on the eager/dask non-VRT paths (whether stable_only=True rejects HTTP/fsspec there) is tracked separately as a behavior fix. This issue corrects the docstring to describe the contract as it should read once enforced, without touching enforcement code.

Additional context

• Affected docstrings: xrspatial/geotiff/__init__.py:721, xrspatial/geotiff/_backends/dask.py:128.
• Related: the VRT rejection under stable_only=True already landed in Reject VRT sources under stable_only=True (#2443) #2447 (issue Reject mixed-tier VRT child sources under stable_only=True (epic #2342) #2443).