Decode TIFF predictor=3 by file byte order so big-endian floats read exactly

[brendancol]

Summary

• The floating-point predictor (TIFF Tech Note 3) byte-swizzles each row into bps lanes, MSB first. The decoder un-transposed those lanes assuming the output was always little-endian: MSB landed at byte index bps-1 of each output sample. Big-endian predictor=3 files therefore decoded into samples with the bytes in the wrong order, which silently produced garbage float values - the array still came back as a clean float32/float64.
• The fix threads the file's byte order into the un-transpose on CPU and GPU. BE files put the MSB at byte index 0; LE files are unchanged. The GPU output also needed a final byteswap because cupy interprets the byte-stream view as native little-endian.

Repro before the fix

import tifffile, numpy as np
arr = np.array([[1.0, 2.0, 3.0, 4.0]], dtype='float32')
tifffile.imwrite('/tmp/be.tif', arr, byteorder='>',
                 predictor=3, compression='deflate')

from xrspatial.geotiff._reader import read_to_array
print(read_to_array('/tmp/be.tif')[0])  # before: garbage like 4.6e-41

Test plan

• New test_predictor3_big_endian.py: float32 and float64 BE round-trip
• BE predictor=3 with tiled layout (multiple tiles)
• LE predictor=3 still round-trips (no regression)
• GPU BE predictor=3 parity with CPU
• Existing predictor and writer tests pass

[brendancol]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in 32b7e3c. Two conflicts:

• __init__.py: combined the sparse-tile CPU-fallback added in main with the byte_order=header.byte_order argument from this branch (both inside the else block).
• _reader.py: formatting-only conflict (single-line vs two-line function signature) — chose the two-line style.