jpegr: fix EXIF offset with preceding JPEG markers

[gregbenz]

Summary

When API 4 combines a compressed SDR JPEG containing EXIF with a compressed gain map, libultrahdr removes and re-adds the EXIF segment. The previous offset was calculated from libjpeg's saved-marker list, which does not include every valid JPEG marker. If COM, APP14, DQT, or marker fill bytes appeared before EXIF, the offset could point to the wrong bytes, corrupting the primary JPEG or causing recombination to fail.

This change finds the selected EXIF payload in the original JPEG header, checks the segment boundaries before copying, and handles repeated marker fill bytes while rebuilding the primary JPEG.

Regression tests cover marker ordering, distinct duplicate EXIF segments, COM, APP14, DQT, marker fill bytes, and API 4 recombination.

Fixes #474

Testing

• Complete CMake/CTest suite with UHDR_ENABLE_WERROR=ON
• Focused ASan/UBSan regression suite
• Windows x64 cross-compilation with warnings treated as errors

[DichenZhang1]

LGTM! Thanks for diagnosing this and providing comprehensive test coverage for marker ordering, fill bytes, and unretained segments.

I have opened a small follow-up PR with minor typing and bounds hardening for find_marker_payload_offset (using uint8_t marker_code and guarding against potential long overflow): #477