RafDecoder: read the aspect ratio dialed in on the camera

[hennikul]

Supersedes #986, which was closed so the work could be squashed into a single
commit. Same change, plus the two fixes that testing forced out.

AI disclosure

Per AGENTS.md, this change was written with AI assistance (Claude Code
with Claude Opus 5). I have read and reviewed it, it builds clean, and I bear
responsibility for it. I am happy to argue any part of it.

What

Fujifilm bodies with an aspect ratio setting record the choice but leave the
raw data uncropped. Consumers therefore see the full sensor readout and the
framing chosen while shooting is lost, where other raw processors reproduce
it and let the user take it back.

The value is tag 0x0115 in the same Fujifilm proprietary directory that
RafDecoder::getDefaultCrop() already reads 0x0110 and 0x0111 from:

• FUJI_RAWIMAGEASPECTRATIO = 0x0115 in TiffTag.h, aliasing
  SAMPLESPERPIXEL the same way FUJI_RAWIMAGECROPTOPLEFT aliases MODEL
• the tag listed among those FiffParser reads as SHORT; left to the
  default UNDEFINED its count is the byte length rather than the number of
  shorts and the entry cannot be read at all
• ImageMetaData::cameraAspectRatio, an Optional<std::array<int, 2>>
• read it in RafDecoder::decodeMetaDataInternal(), ignoring it when it
  matches the cropped size, since the tag is written whether or not a ratio
  was picked and reporting a native 3:2 would have consumers crop every raf

Why a ratio and not a rectangle

The box a vendor describes is relative to that vendor's own output area,
which is not the area rawspeed hands out. A consumer given a rectangle would
have to track that difference per vendor; a consumer given a ratio can center
it on whatever it actually received. It is also all there is here: Fujifilm's
RawImageCroppedSize beside this tag stays at the native shape whatever
ratio is selected, so there is no usable rectangle to hand out.

The field is named for the concept rather than for Fujifilm, so the other
decoders can fill it as and when someone does that work.

Testing

CC0 samples from raw.pixls.us, consumed end to end through darktable:

Sample	Shot at	Result
X-T200 DSCF0074.RAF	16:9	reports {16, 9}, exports 16:9
X100V DSCF0734.RAF	native 3:2	reports nothing, exports full frame

The X100V pair also settles the byte order, reading (2, 3) against a
cropped size of (4160, 6240), so height first, as getDefaultCrop()
already assumes for the sibling tag.

Both problems above were found by running it rather than by reading it, which
is worth saying plainly: as first submitted to #986 this read nothing at all,
and once reading, it would have cropped every raf.

Not covered: fuji_xe4_32_lossy.RAF from the same database fails to
decompress on current develop with "compressed RAF header check". That is
unrelated and happens before this code, but it leaves lossy compressed rafs
unverified here.

Happy to add a test if you point me at where a sample would live.

Context

The consuming side is darktable-org/darktable#22088, which reproduces this
framing as an editable crop and already reads Canon and Olympus through
Exiv2. Fujifilm cannot be read that way, the value being in the raf container
rather than the Exif makernote, which is why it wants doing here. Consuming
this field is a follow-up and not part of this PR.