Multiple ModelTiepoints are silently collapsed to the first tiepoint

[brendancol]

Describe the bug

_extract_transform in xrspatial/geotiff/_geotags.py:536-547 reads only tiepoint[0:6] and ignores any additional tiepoint records:

tp_i = tiepoint[0] if len(tiepoint) > 0 else 0.0
tp_j = tiepoint[1] if len(tiepoint) > 1 else 0.0
tp_x = tiepoint[3] if len(tiepoint) > 3 else 0.0
tp_y = tiepoint[4] if len(tiepoint) > 4 else 0.0

A ModelTiepointTag (33922) may carry one or many (I, J, K, X, Y, Z) tuples. The single-tiepoint + ModelPixelScale case is the common one and is fine. Multi-tiepoint files are used to encode either:

1. The same affine derived from each of N corners (the tuples agree within tolerance), or
2. A non-affine warp ground-control-point set (the tuples do NOT agree).

In case (1) the reader silently picks the first tuple and gets the right answer by luck. In case (2) the reader fabricates an axis-aligned affine from the first tiepoint, which is wrong: downstream spatial ops then operate on coordinates that do not match the file's actual ground control.

Expected behavior

When ModelTiepointTag carries more than one tuple, the reader should validate that every tuple is consistent with the inferred affine (within a tolerance scaled to pixel size). If they agree, the read proceeds. If they disagree, raise a clear error pointing at the GCP case rather than silently producing wrong coordinates.

A future opt-in could add fitting a least-squares affine to the GCPs, but that is follow-up.

Additional context

• The check should fire on both ModelTiepoint + ModelPixelScale and ModelTiepoint alone.
• An error message should distinguish "multiple tiepoints, all agreeing" (passes) from "tiepoint disagreement -> GCP warp not supported".