gamut-tiff: a dangling IFD-0 pointer costs a single-page file its C2PA store, while a two-page file recovers

[justin13888]

TiffDecoder::metadata resolves ExifIFD/InteroperabilityIFD over IFD 0's subtree only, so
a dangling pointer on any later page cannot fail the call (#520). One shape is left asymmetric by
that rule, and the asymmetry is not obvious from either side:

• two-page file, dangling ExifIFD on page 1, C2PA manifest store in the last IFD: the call
  succeeds and the store comes back, because page 1's pointers are never resolved
  (a_broken_pointer_on_a_page_the_metadata_discards_does_not_fail_the_read);
• one-page file, same dangling ExifIFD, same store — IFD 0 is the last IFD, so resolving
  IFD 0's subtree fails, and the caller loses the store (and XMP, IPTC and ICC) to a pointer none
  of them came from (a_broken_exif_pointer_is_still_an_error).

The single-page refusal is deliberate as far as EXIF goes: the Exif directory is a returned
field, and reporting exif: None for a directory the file declares is silent loss. The question is
whether the other four carriers should share its fate when they are all present in the same
directory and all readable.

Options, none free:

1. keep it — one error for one file, at the price that a broken pointer costs a single-page file
   the metadata it does carry;
2. return the blocks and report the Exif failure out of band, which needs a partial-result shape
   TiffMetadata does not have (and gamut-dng solves by degrading silently, which this crate
   deliberately does not);
3. resolve pointers after the opaque blocks have been read, and fail with them already collected
   — same type, different error contract, and it makes success/failure depend on read order.

Filed from the review of #520; the behaviour is documented on TiffDecoder::metadata today, so
this is a contract question rather than a defect.