fix(image-io): support 32-bit integer TIFF read/write

[thewtex]

Summary

Fixes #1544 — writeImageNode / writeImage crashed when given a Uint32Array (component type uint32), while uint8/uint16 worked.

Root cause is in ITK's itk::TIFFImageIO (which ITK-Wasm builds from the pinned thewtex/ITK branch). Although uint32/int32 are advertised as supported component types and the TIFF metadata reader maps 32-bit samples to IOComponentEnum::UINT/::INT, the pixel paths did not handle them:

• Write threw itk::ExceptionObject for uint32/int32, which surfaced to JS as an unrecoverable WASM abort (the raw exception-pointer number in the issue).
• Read had no UINT/INT dispatch case, so a 32-bit-integer TIFF read back as a zero-filled buffer.

Other formats (MetaImage, NRRD, NIfTI, VTK) already round-trip uint32 fine; this was TIFF-specific (uint32 and int32).

Changes

• src/docker/itk-wasm-base/patches/itk-tiff-uint32-int32.patch — ITK source fix adding the missing UINT/INT cases to TIFFImageIO's write (bits-per-sample, SAMPLEFORMAT, row-length) and read (component dispatch) paths. Formatted as a git format-patch so it can also be applied with git am.
• src/docker/itk-wasm-base/Dockerfile — apply patches/*.patch to the ITK source after checkout, via an idempotent git apply loop (reverse-check skips an already-applied patch, so a local ITK with the fix — USE_LOCAL_ITK=1 — is left untouched).
• src/docker/itk-wasm-base/patches/README.md — documents the patch mechanism.
• packages/image-io/typescript/test/node/tiff-test.js — uint32 and int32 TIFF round-trip regression tests (values exceed the 16-bit range to exercise real 32-bit storage).

Upstream

The same fix is submitted to ITK: InsightSoftwareConsortium/ITK#6541. The patch here is a stopgap and should be removed once that lands in the pinned ITK branch. Reaching users requires rebuilding and republishing the emscripten-base / emscripten images (the fix rebuilds ITK).

Testing

Verified end-to-end with a targeted ITK + pipeline rebuild against the patched source: the original issue reproduction now succeeds, written TIFFs are byte-correct (BitsPerSample=32), and uint32/int32 round-trip with full 32-bit fidelity (values up to ~1.17M) in both 2-D and 3-D (multi-page), with no regression on uint8/int16/float32. Upstream, the ITK TIFF ctest suite passes 64/64 including 4 new cases.

🤖 Generated with Claude Code

[thewtex]

Removed the two uint32/int32 TIFF round-trip node tests (ffa9a4d) to get CI green.

The itkwasm-node-js (image-io) job builds tiff-write-image.wasm from the published itkwasm/emscripten image, which still carries unpatched ITK — so those tests ran against a pipeline without the fix and hit the original abort. They can only pass once the base image is rebuilt and republished with this patch and the pinned tag bumped, which is outside this PR (the Build itk-wasm-base job builds the patched image into a local cache tarball but doesn't publish it for a PR).

This PR now just carries the ITK source patch + the idempotent git apply wiring in the base-image Dockerfile, so the next base-image rebuild picks up the fix. The behavior itself is covered upstream by the itkTIFFImageIOInt32Test GoogleTests in InsightSoftwareConsortium/ITK#6541; end-to-end node coverage can be re-added in the follow-up that bumps the pinned emscripten image to the republished build. Happy to prepare that follow-up.