geotiff: non-VRT read paths accept band=True / band=False

[brendancol]

Describe the bug

The non-VRT read paths only range-check the band argument:

ifd_samples = ifd.samples_per_pixel
if band is not None:
    if ifd_samples <= 1:
        if band != 0:
            raise IndexError(...)
    elif not 0 <= band < ifd_samples:
        raise IndexError(...)

at xrspatial/geotiff/_reader.py:2385. Because True == 1 and False == 0 in Python, band=True reads band 1 and band=False reads band 0 without complaint. The VRT path already rejects bool explicitly. The dask and GPU paths inherit the same range-only check.

This is a small API inconsistency on a core selector. A user who accidentally writes band=some_truthy_flag gets a silently shifted read instead of an error.

Expected behavior

open_geotiff, read_to_array, the HTTP/COG path, the GPU path, and the dask path should all reject bool values for band with the same TypeError the VRT path uses, before the range check.

Categories

• Cat 5 (backend inconsistency): VRT rejects bool, other paths accept it
• Cat 3 (input validation): API contract drift on a core selector