geotiff: write_geotiff_gpu compression docstring lists 4 codecs but accepts the full 9

[brendancol]

Summary

write_geotiff_gpu documents only 'zstd', 'deflate', 'jpeg', and 'none'
under its compression parameter, but the implementation accepts every codec
that to_geotiff does. Codecs unsupported by nvCOMP fall through to the CPU
encoder transparently (see gpu_compress_tiles -> cpu_compress).

Reproducer (CUDA host required):

import cupy, numpy as np, xarray as xr, tempfile, os
from xrspatial.geotiff import write_geotiff_gpu
data = cupy.random.rand(64, 64).astype(cupy.float32)
da = xr.DataArray(data, dims=['y','x'],
                  coords={'y': np.arange(64.0), 'x': np.arange(64.0)},
                  attrs={'crs': 4326})
with tempfile.TemporaryDirectory() as d:
    write_geotiff_gpu(da, os.path.join(d, 't.tif'), compression='lzw')   # OK
    write_geotiff_gpu(da, os.path.join(d, 't.tif'), compression='lerc')  # OK

Sibling to_geotiff documents the full 9-codec list. The same applies here:
users reading write_geotiff_gpu.__doc__ (or IDE hover) would conclude that
LZW, LERC, JPEG 2000, PackBits, and LZ4 are unsupported, when in fact they
work and produce identical bytes to the CPU writer (just without GPU
acceleration of the compression stage).

This was missed by PR #1633 which addressed overview_resampling='cubic'
and the data type annotation but not the codec list.

Severity

MEDIUM (Cat 3 -- docstring disagrees with behaviour).

Fix

Sync the compression docstring against the actual accepted set (mirror
to_geotiff's wording) and note which codecs run on GPU vs. CPU
fallback so users understand the performance trade-off.

Deprecation impact

None. Doc-only change; no signature change.

Found by /sweep-api-consistency on 2026-05-11.