fix(geotiff): decode big endian tiles in the platform's byte order

[james-willis]

Closes #686.

Big endian (MM) TIFFs decoded to byte-swapped pixel values: toTypedArray views the decoded bytes in the platform's byte order, and DecoderMetadata didn't carry the file's.

Changes

• DecoderMetadata gains an optional littleEndian (default true, so existing callers of decode() are unaffected). fetch.ts sets it from image.tiff.isLittleEndian for both data and mask tiles.
• decode() byte-swaps samples wider than 8 bits from big endian files, before applyPredictor, since horizontal differencing (predictor 2) has to accumulate native-order integers.
• Predictor 3 is excluded: its byte planes are most significant byte first in every file (TIFF Technical Note 3), and decodeRowFloatingPoint already reassembles them in platform order.
• The swap writes to a new buffer, because the uncompressed decoder returns the caller's bytes, which may be shared with the block cache.
• Codecs that return typed pixels (LERC, JPEG, WebP) don't go through this path and are unchanged.

Tests

Three unit tests in decode.test.ts build big endian tiles from known values:

• float32, no predictor (also asserts the input buffer is untouched)
• uint16, predictor 2
• float32, predictor 3, decoded as both II and MM, which must agree

The first two fail on main; the third fails if the swap is applied to predictor 3. pnpm typecheck and biome check are clean. Locally, integration-rasterio.test.ts fails on missing .npy reference files in my fixtures checkout, the same with and without this change.

[kylebarron]

Thanks!

Could you make a PR to add a big-endian TIFF to https://github.com/developmentseed/geotiff-test-data so that we have a known TIFF to test against?