parse_ifd raises raw struct.error before bounds checks on truncated TIFFs

[brendancol]

Describe the bug

The typed-error work from #1661 (commit 58a8b3d) covered the IFD value area, but the entry-table parse in xrspatial/geotiff/_header.py:parse_ifd still calls struct.unpack_from for the entry count and each entry's tag/type/count fields before checking that the IFD region fits in len(data):

• Lines 478-486: num_entries is unpacked at offset without verifying that offset + 2 (or + 8 for BigTIFF) is in range.
• Lines 502-514: each entry's tag, type_id, count are unpacked without checking entry_offset + i * entry_size + entry_size <= len(data).
• Lines 559-563: the next-IFD pointer is unpacked at entry_offset + num_entries * entry_size without bounds checking.

A truncated or crafted file lands on struct.error: unpack_from requires a buffer of N bytes, which escapes the typed ValueError contract that the Hypothesis fuzz tests in test_geotiff_fuzz.py rely on.

Expected behavior

Truncated or crafted TIFF inputs raise ValueError naming the offending offset and remaining buffer size.

Suggested fix

Add an explicit bounds check against len(data) before each struct.unpack_from call: one for the entry-count read, one inside the per-entry loop, and one before the next-IFD pointer.

Add a Hypothesis strategy that truncates known-good TIFFs to varying lengths and asserts ValueError, not struct.error.

Additional context

Reported during a code review of the geotiff module. Same hardening direction as #1661.