TIFF makes a partial write especially bad: the IFD carries byte offsets
into the same file, so an image whose header landed but whose strips did
not still parses -- it just points at bytes that were never written.
Reading back garbage as a valid image is worse than failing to read.

Two tests over eio-fs's Chaos. Under short writes the image either fails
to write or comes back byte-identical, never a valid TIFF with different
pixels behind its offsets; Eio.File.pwrite_all loops, and this checks the
bridge does not undo that. And a write the filesystem refuses outright
reaches the caller rather than leaving them believing an image was saved.

optint is pinned to a fork in the development switch for its 31-bit
wasm integer fix, but the package never declared the pin, so an
install from a fresh switch resolved the public optint instead.

Comparing two headers or two tags went through polymorphic (=), which
reads as an accident rather than a decision: nothing at the call site
says whether structural comparison is the intended semantics for these
types, and the operator would keep compiling if a future constructor
carried something it cannot compare.

Endian owns endianness so equal_endianness lives there and Ifd re-exports
it alongside the type alias. equal_tiff_kind is a two-constructor match.
The tag type has thirty constructors whose only payload is an int, so a
hand-written match would be thirty lines restating what a monomorphic (=)
says exactly; the annotation keeps it monomorphic.

A tag whose values fit in the entry's four-byte value field is stored
inline, and a chunky multi-band raster keeps its per-band BitsPerSample
there. The reader collapsed such an inline field to a single Immediate,
so bits_per_sample recovered only the first band (reading [0; 0] for
two), and Tiff.data rejected every chunky multi-band file, GDAL's
INTERLEAVE=PIXEL default, with a zero sample width.

Slice an inline field of more than one value into one buffer per value
at parse time and cache it as a Read, so the multi-value readers serve
it like an out-of-line array. The writer re-inlines a Read that fits.

Geo_keys read the projected CRS (3072) but not the geographic one, so a
geographic (unprojected) GeoTIFF could not have its datum verified from its EPSG
code -- a reader had to fall back to the ellipsoid keys and assume WGS-84 when
they were absent, reading a NAD83 scene about a metre out. The key was already
parsed into the directory (Geographic_type_geo_key); it just had no accessor.

geographic_crs is the exact parallel of projected_crs. The Landsat mission
products carry no explicit 2048 key, so the interop suite now asserts
geographic_crs raises Not_found on them -- which is real evidence for the
ellipsoid-fallback path a reader needs. The positive case wants an unprojected
fixture the GDAL regen must add; filed rather than faked.