geotiff: mixed SampleFormat per band is silently collapsed to first band #1868

Describe the bug

IFD.sample_format in xrspatial/geotiff/_header.py:165 returns v[0] when the TIFF SampleFormat tag is a tuple. That collapses per-band sample formats to whatever the first band has.

Mixed BitsPerSample is rejected by resolve_bits_per_sample with a typed error pointing at gdal_translate. Mixed SampleFormat is not. A file that declares BitsPerSample=(32,32,32) and SampleFormat=(3,3,1) (two float bands plus one uint band) decodes every band as float32 instead of failing.

For mixed signed/unsigned/float with equal bit depth this is silent pixel corruption. The integer band is reinterpreted as a different numeric type and the user gets wrong values back with no warning.

Expected behavior

Mixed SampleFormat tuples should raise ValueError with a message that tells the user the file is unsupported and how to convert it, the same way mixed BitsPerSample does. Empty SampleFormat tuples should keep falling back to the default (uint, value 1). That case is covered by the fuzz regression at tests/test_fuzz_hypothesis_1661.py:311 and the fallback is intentional.

Additional context

• Caller sites: _reader.py:2507, _reader.py:2934
• Existing pattern to mirror: _dtypes.resolve_bits_per_sample
• Severity: HIGH (silent corruption of decoded pixel values).