RafDecoder: read the aspect ratio dialed in on the camera

[hennikul]

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, so
this is a small addition rather than new parsing:

• FUJI_RAWIMAGEASPECTRATIO = 0x0115 in TiffTag.h, aliasing
  SAMPLESPERPIXEL the same way FUJI_RAWIMAGECROPTOPLEFT aliases MODEL
• ImageMetaData::cameraAspectRatio, an Optional<std::array<int, 2>>
• read it in RafDecoder::decodeMetaDataInternal()

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 just
center it on whatever it actually received. It is also the only thing some
vendors record - Fujifilm's own RawImageCroppedSize beside this tag holds
the native area, not the selected one, so there is no usable rectangle here
in the first place.

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.

Untested - a Fujifilm owner is needed

I have no Fujifilm body and no raf file to try this on. What I did check:

• the tag number and its two-entry layout come from ExifTool's
  FujiFilm::RAF table
• cross-checked against LibRaw, which reads the same tag in
  src/metadata/fuji.cpp and maps it to raw_aspect
• the height-then-width order matches FUJI_RAWIMAGECROPPEDSIZE, read a few
  lines away in getDefaultCrop() with the same ordering
• hasEntryRecursive() guards the lookup, since getIFDWithTag() throws and
  not every raf carries that directory
• builds clean

None of that substitutes for running it on a real file. If someone with a
Fujifilm body that has an aspect ratio setting could verify that a raf shot
at 1:1 or 16:9 comes out with cameraAspectRatio set to the matching pair,
and that ordinary raf files are unaffected, I would be grateful. I am happy
to add a test if you can point me at where a sample would live.

Context

This is the missing half of darktable-org/darktable#22088, which reproduces
this framing as an editable crop. That side reads the ratio through Exiv2,
which reaches Canon but cannot see Fujifilm's - the value is in the raf
container rather than the Exif makernote, which is why it wants doing here.
Consuming this field in darktable is a follow-up and not part of this PR.

[hennikul]

It is no longer untested. @gi-man pointed me at raw.pixls.us on the darktable
side, and there is a suitable sample there: Fujifilm X-T200 DSCF0074.RAF,
shot at 16:9.

Two things were wrong with what I first pushed, both of which only running it
could have shown.

The entry was parsed as UNDEFINED. FiffParser has an allow-list of raf
tags treated as SHORT, and I had not added the new one, so its count came
out as the byte length and RafDecoder skipped it. As submitted the first
commit read nothing at all.

The tag is present even at the native ratio. A plain 3:2 frame carries
RawImageAspectRatio too, so reporting it unconditionally would have had
consumers crop every raf to an exact 3:2 and trim the sensor margins off
images nobody chose a ratio for. It is now compared against
RawImageCroppedSize in the same directory, which stays at the native shape
whatever ratio is selected, and only a ratio that differs is reported.

Verified end to end through darktable with the field consumed:

Sample	Ratio	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 samples also settle the byte order I had inferred rather than observed:
the X100V pair reads (2, 3) against a cropped size of (4160, 6240), so
height first, as getDefaultCrop() already assumes for the sibling tag.

One thing I could not test: fuji_xe4_32_lossy.RAF fails to decompress on
current develop with "compressed RAF header check". That is unrelated to this
change and happens before it, but it means lossy compressed rafs are
unverified here.

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

Disclosure, per AGENTS.md: written with AI assistance (Claude Code with
Claude Opus 5). I have reviewed it and take responsibility for it.