Add 21 JXL files exposing libjxl/jxl-rs LZ77 distance-cluster bug

These VarDCT bitstreams use Optimal or Greedy LZ77 backward references
(produced by imazen/jxl-encoder at e9 + low distance on screen content).
libjxl djxl 0.12.0 and jxl-oxide 0.12.5 decode them cleanly; libjxl/jxl-rs
v0.4.3 rejects all of them with Invalid AC: N nonzeros after decoding
block (root cause: context_map padding shifted the LZ77 distance cluster
away from context_map.last(); fix in libjxl/jxl-rs#766).

libjxl's encoder pins LZ77 to kRLE for VarDCT at every effort tier
(enc_ans_params.h + enc_frame.cc:1259-1263), so existing libjxl test
corpora don't exercise the Optimal/Greedy LZ77 + VarDCT code path.
Adding these files to the conformance corpus so any future jxl-rs
or jxl-oxide regression in this area is caught.

Files split into two clusters:
- akfcrc022_e9_d{1.5,2.0,3.0}: 3 files, 22-29 KB each (smallest reproducer
  is akfcrc022_e9_d3.0.jxl at 22 KB; also committed in-tree to
  imazen/zenjxl-decoder/tests/testdata/)
- gb82-sc_*_d{0.25,0.5,1.0,1.5,2.0}: 18 files, 32-447 KB; screen-content
  variants (terminal, gui, codec_wiki, gmessage, graph, imac, windows)
  at varying distances

References regenerate via jxl/generate_references.sh.

Refs:
- libjxl/jxl-rs#765 (bug)
- libjxl/jxl-rs#766 (fix)
- imazen/zenjxl-decoder#15 (downstream tracking)
- imazen/jxl-encoder#29 (encoder default rationale)

Author: lilith