Fix progressive JPEG AC refinement ZRL handling in Iris decoder

[korale77]

Problem

ds4_image_decode_* failed on many progressive JPEGs, including plain
cjpeg -progressive output and files produced by common tools. Symptoms were
either jpeg_load returning NULL ("could not load image") or a successful
decode with wrong pixels.

Root cause

In third_party/iris/jpeg.h, jpeg_prog_decode_ac_refine mishandled the
ZRL symbol (run=15, size=0) in successive-approximation AC refinement scans
(Ah != 0). It set run = 16 and reused the skip loop, which:

1. skipped 16 zero-history coefficients (correct), then
2. kept walking and consuming correction bits for every non-zero coefficient
   after the 16th zero, until it reached a 17th zero.

Per ITU T.81 G.1.2.3 (and libjpeg's decode_mcu_AC_refine), the correction
bits for those trailing non-zero coefficients belong after the next Huffman
symbol. Consuming them early desynchronises the bitstream for the rest of the
block/scan: usually the next symbol decodes as an invalid size and the whole
image fails, otherwise the coefficients come out subtly wrong.

The fix unifies the ZRL and size==1 paths: skip run zeros while refining
non-zeros on the way, write new_val (0 for ZRL) at the (run+1)-th zero, and
stop. This matches libjpeg's structure exactly. The upstream Iris repository
(antirez/iris.c, jpeg.h at HEAD) still has the bug; I will send the fix there too.

Testing

Machine: Apple M5 Max, macOS 25.5, clang, default make (Metal backend).

New regression test tests/test_image_decode (wired into make test)
decodes two committed fixtures generated with libjpeg-turbo 3.2.0 cjpeg
(tests/vision-fixtures/jpeg/generate.sh recreates them byte-identically):

Fixture	Before	After
prog_ac_refine_zrl_gray.jpg (24x16 gray)	decodes, 64/384 bytes differ from djpeg (max 11)	bit-exact with djpeg
prog_ac_refine_zrl_420.jpg (64x48 4:2:0)	jpeg_load returns NULL	decodes, max diff 1 vs djpeg -nosmooth

Differential check of old vs new decoder against djpeg over 25 images
(baseline, progressive 4:4:4/4:2:2/4:2:0, grayscale, restart intervals,
q50-q100, custom multi-refinement scan scripts, and the 1600x309 image that
triggered the report):

• Old decoder returned NULL on 15 of 25 images (every default
  cjpeg -progressive 4:2:0 encode of the earth fixture, every 4:2:2/4:2:0
  restart-interval variant, and the reporting image). New decoder decodes all 25.
• On the 8 images where both decoders succeeded and the scan has no
  refinement ZRL, old and new outputs are byte-identical (no behaviour change
  for baseline or non-affected progressive files).
• New decoder vs djpeg: grayscale is bit-exact; colour images differ by
  at most 1/255 vs djpeg -nosmooth (Iris uses box chroma upsampling; the
  remaining delta is the pre-existing upsampler/IDCT difference, identical to
  what baseline JPEGs already show).
• ASan+UBSan build decodes the full corpus cleanly. 240 truncated/bit-flipped
  variants of the fixtures: no crashes or hangs introduced; the two UBSan
  reports found (shift exponent in jpeg_get_bits, jpeg_zigzag[64] when a
  corrupt SOS sets Se > 63) reproduce identically on the unpatched decoder and
  are left for a separate PR.
• Full make test passes, including the model-backed ds4_test runs against the local DeepSeek 4 Flash GGUF.
• -Wall -Wextra -std=c99: no new warnings.

🤖 Generated with Claude Code