open_geotiff: source kwarg lacks str | BinaryIO type annotation

[brendancol]

Summary

The api-consistency sweep on 2026-05-12 found that open_geotiff(source, ...) lacks a type annotation on its source parameter, while sibling reader and writer functions on the same public surface are annotated.

Detail

Current signature (xrspatial/geotiff/init.py:644):

def open_geotiff(source, *, dtype=None,
                 window: tuple | None = None,
                 ...

source has no annotation. The docstring documents str or binary file-like:

source : str or binary file-like
    File path, HTTP URL, cloud URI (s3://, gs://, az://), or a
    binary file-like object (e.g. io.BytesIO) with read+seek.

Sibling functions:

• read_geotiff_gpu(source: str, ...)
• read_geotiff_dask(source: str, ...)
• read_vrt(source: str, ...)

Sibling writers that accept file-like:

• to_geotiff(data, path: str | BinaryIO, ...)
• write_geotiff_gpu(data, path: str | BinaryIO, ...)

The annotation gap on open_geotiff(source) reads as a documentation bug: type checkers and IDEs cannot see that BytesIO is accepted, even though it works at runtime and is documented.

PR #1654 annotated window, path, and on_gpu_failure across the public surface but skipped source on open_geotiff. This issue closes that gap.

Severity

MEDIUM (Cat 3, type hints / docstring drift). Surface-only fix; no runtime behaviour change, no deprecation impact, no defaults change. BinaryIO is already imported under TYPE_CHECKING in the module so the runtime cost stays at zero.