GPU predictor decode kernel over-indexes d_decomp for multi-sample tiled TIFFs #1220

In _gpu_decode.py, the predictor=2 path passes wrong arguments to _predictor_decode_kernel for tiled TIFFs with SamplesPerPixel > 1.

The kernel computes row_bytes = width * bytes_per_sample. Call sites need width in pixels and bytes_per_sample = itemsize * samples. Both current call sites multiply width by samples as well:

_predictor_decode_kernel[bpg, tpb](
    d_decomp, tile_width * samples, total_rows, dtype.itemsize * samples)

So row_bytes ends up tile_width * samples^2 * itemsize instead of tile_width * samples * itemsize. The inner loop walks samples times further than the row actually extends, reading and writing past the end of each tile's row, and on the last tile past the end of d_decomp itself. OOB GPU write, with no error surface.

Call sites:

• xrspatial/geotiff/_gpu_decode.py:1339-1340 (_apply_predictor_and_assemble, GDS path)
• xrspatial/geotiff/_gpu_decode.py:1583-1584 (gpu_decode_tiles, non-GDS path)

Kernel body: xrspatial/geotiff/_gpu_decode.py:586-598.

For reference, the CPU path does it right. _reader.py:290-291 calls _apply_predictor(chunk, pred, width, height, bytes_per_sample * samples) with pixel width, and _compression.py:338-349 uses the same row_bytes = width * bytes_per_sample formula. The writer (_writer.py:398) matches.

Reproduction: tiled TIFF, SamplesPerPixel > 1, Predictor = 2, GPU decode path (e.g. read_geotiff_gpu). For samples=3 it writes 3x the intended bytes per row; for samples=4 it's 4x.

Effects:

• Wrong decoded pixels (the cumulative-sum runs off the end of each row into the next one).
• OOB write past d_decomp on the last tile.

Fix: pass width=tile_width at both call sites. bytes_per_sample=itemsize * samples stays as is. No kernel change.

The predictor=3 path has its own argument pattern (bytes_per_sample=itemsize, no * samples) that looks suspicious for multi-sample data too, but that's a separate bug.