geotiff: open_geotiff(gpu=True) does not forward on_gpu_failure kwarg

[brendancol]

Summary

open_geotiff(source, gpu=True, ...) silently drops the on_gpu_failure kwarg. The dispatcher does not declare it, and the GPU branch does not forward it to read_geotiff_gpu. Callers who want strict GPU-failure semantics through open_geotiff have no way to enable them; they must drop down to read_geotiff_gpu directly, which is the entry point the dispatcher is meant to hide.

Same shape as #1561 (kwargs lost in dispatch) and #1605 (window= / band= lost on the GPU branch). The on_gpu_failure kwarg was added in PR #1590 (Closes #1560); the dispatcher was not updated at that time.

Reproducer

from xrspatial.geotiff import open_geotiff
# Wanting strict GPU failure semantics under the dispatcher entry point:
open_geotiff("path/to/file.tif", gpu=True, on_gpu_failure='strict')
# TypeError: open_geotiff() got an unexpected keyword argument 'on_gpu_failure'

Current behavior

open_geotiff(..., gpu=True) always runs the GPU path with on_gpu_failure='auto' (the default in read_geotiff_gpu). GPU failures fall back to CPU with a RuntimeWarning regardless of caller preference. Tests and CI that want a hard GPU failure on regression have to bypass open_geotiff and call read_geotiff_gpu directly.

Expected behavior

open_geotiff should accept on_gpu_failure and forward it to read_geotiff_gpu when gpu=True. Passing the kwarg with gpu=False should raise ValueError since the kwarg only applies to the GPU pipeline (matches the way to_geotiff rejects max_z_error on non-LERC codecs).

Suggested fix

Add on_gpu_failure to the open_geotiff signature with a sentinel default. When gpu=True, forward it to read_geotiff_gpu. When set with gpu=False (or unset), reject up front so callers don't silently get auto behavior.

Severity

Real user-visible API gap. Found via the api-consistency deep-sweep on geotiff.