Stage C fetch jpgQuality=100: golden-set baseline itself is stale (6/32 cards' collector_line_ocr drift before any quality change)

[WilfordGrimley]

The observation

image_cdn_fetch.get_worker_image_url requests every Stage C card image at
jpgQuality=100. Two real fetches at identical dimensions (DPI-capped, confirmed
680x925) came back at 171 KB and 871 KB — a 5x spread driven entirely by content,
with quality 100 refusing to compress either. Stage C is fetch-bound (the pooled
design's ceiling is the fetch term, not compute), so bytes on the wire translate
fairly directly into pass throughput. Lowering jpgQuality was the natural next
question.

Why this needs the golden set, not a guess

Several extractors decide on pixel variance, and JPEG compression is exactly what
perturbs variance: classify_border_color and classify_bleed_edge both
threshold on standard deviation (228,914 and 2,786 cast votes respectively), and
quality_signals is compression-sensitive by construction. A quality drop that
silently moved layout_class would mis-tag the catalogue at scale. golden_set.py
pins expected values for 32 cards across 11 extractor groups specifically so a
drift like this shows up as a named field mismatch on a named card, not a
judgement call.

Result: blocked at step 0, not step 5

Ran the golden set's own no-persistence method (compute_card_evidence against a
freshly fetched, freshly decoded image, no DB writes) at jpgQuality=100 — the
literal current production value — to confirm the harness reproduces the fixture
before touching the quality variable at all. It does not, cleanly.

• 9 of 11 groups reproduce exactly, all 32/32 cards: fetch_health,
  geometry_bleed, layout_class, crop_coordinates, artist_ocr,
  symbol_region, legal_line, quality_signals — including the two
  pixel-variance-threshold extractors (classify_border_color,
  classify_bleed_edge) this whole investigation exists to protect. This is
  strong evidence the actual fetched image bytes are unchanged from whatever
  produced the pins.
• bleed_diff_mm "drifts" on 30/32 cards — but this is a documented,
  pre-existing issue already called out in golden_set.py's own comment:
  compute_bleed_diff_mm rounds to 4 decimal places and always has, but the
  original 30 pins carry full float precision (e.g. pinned
  -0.018877551020422434 vs. real output -0.0189). Not a new finding, not
  quality-related.
• collector_line_ocr/collector_line_tsv genuinely drift on 6/32 cards
  (35, 147855, 193523, 199986, 208337, 214113) — real, different OCR reads
  (e.g. card 208337: pinned set_code "ahr", real run "dns"; card 214113:
  pinned "cls", real run "tla" — both plausible-looking real set codes,
  not garbage, consistent with genuine tesseract escalation-tier reads rather
  than a broken harness). Ruled out as an environment artifact: tesseract-ocr
  (4.1.1-2.1build1) and tesseract-ocr-eng (traineddata dated 2017-09-15) are
  long-installed, stable system packages, unchanged since the pins were
  recorded. The far more likely explanation is that collector_line_ocr's own
  pipeline has had substantial, legitimate development since the 2026-07-19 pin
  date (the lexicon gate, the artist-recovery gate, the Stage C OCR passes: collapse the 4x attempt ladder and the duplicated bottom-band read (4 passes -> 2) #677 ladder collapse)
  and the original 30 cards' OCR values were never re-verified against current
  code — only the 2026-08-05 additions (35449/130028) were.

Per this task's own stop condition ("if you cannot reproduce the baseline, stop
and report — everything downstream is meaningless if the harness disagrees with
the fixture before any variable is changed"), the quality ladder (95/90/85/75...)
was not run. Any OCR-field drift observed at a lower quality on these same 6
cards would be indistinguishable from this pre-existing baseline noise, and
extending stale, unrelated noise into a "quality changed X" conclusion would be
worse than not measuring at all.

What this does confirm

The 9 non-OCR groups — specifically including the two variance-threshold
classifiers this issue is actually about — are cleanly reproducible against the
current fixture at jpgQuality=100. That part of the golden set is usable as a
gate for a future quality-ladder measurement once the fixture itself is current.
jpgQuality remains unchanged at 100; no code was shipped by this measurement.

Recommended follow-up (not done here, out of this task's scope)

1. Re-verify (or re-record) collector_line_ocr/collector_line_tsv pins for
   the original 30 golden cards against current master — a fixture staleness
   fix independent of any quality change.
2. Normalize bleed_diff_mm's golden-set comparison to 4 decimal places (or
   re-round the 30 pre-2026-08-05 pins) so this documented discrepancy stops
   surfacing as a false drift on every future golden-set comparison.
3. Once (1) is done, re-run the quality ladder (100/95/90/85/75) this issue
   was meant to answer — the harness (compute_card_evidence called directly
   against a real CDN fetch, no persistence) is built and works; it just needs
   a baseline it can actually match first.

Golden-set affected-population note

Of the 32 golden cards, only 7 (102138, 128981, 147855, 175889, 194684, 199986,
208569 — 21.9%) come back as JPEG at all; the other 25 are PNG, for which
jpgQuality is a no-op. A saving here, once measured, applies to roughly a fifth
of this sample — whether that generalizes catalogue-wide is a separate open
question the golden set's 32-card, source-stratified (not format-stratified)
sample can't answer on its own.