Update visual regression baselines for the QR badge rework (BL-16638)

[andrew-polk]

Regenerates the 22 visual-regression baselines that BL-16370's QR badge rework invalidated. Reference images only — no source changes (git diff --name-only origin/master..HEAD is 22 PNGs), so the code under test is byte-identical to master.

Why the suite was red

BL-16370 changed how the back cover renders and landed without regenerating baselines, so the nightly has failed since. Every change below is that ticket's intended design:

• The "Made with Bloom" badge caption becomes "More books in <language> language:" over a BloomLibrary.org/language:<tag> link, and the QR code re-encodes to that language-specific address rather than the site root.
• Local-Community swaps the Bloom tulip over "Local" for a gift box over "Bloom Local", gains the QR badge on its back cover (it carried none before), and rewrites its back-cover subscription paragraph, which also loses the white box it used to sit in.

Both rendering paths, and why half of this was invisible

The preview and bloom-player render the book separately, so each has its own baselines: 10 whole-book preview captures and 12 bloom-player page captures.

The player ones had never been compared even once since BL-16370. A case captures its preview first, then walks player pages in order, and every comparison throws on failure — so a stale preview aborted each case before any player page was captured, and a stale player page hid every page after it. Only after the preview baselines were accepted did the player set become visible at all. Two of them (both Local-Community back covers) had never been captured by any run in this suite's history.

To avoid discovering this one layer per run, the comparison was made non-fatal for a single local diagnostic run so all 84 images were captured at once; that change was reverted before committing (index.spec.ts is untouched in this PR).

Deliberately not updated

A5 Portrait / theme-rounded-border-ebook-player-p1 differs by 51 pixels under a more sensitive threshold, but pixelmatch counts zero differing pixels at the threshold the suite asserts on. That is sub-threshold anti-aliasing jitter, not a real change; rewriting the baseline would risk baking run-to-run noise into it.

Verification

• Full suite green at this HEAD: 12 of 12 cases pass, all 84 images compared and matched, with the real assertion in place.
• The five 16x9 preview counts reproduced the CI run exactly (6307 / 91808 / 6307 / 6307 / 6272), confirming these locally generated baselines match what the Release build in CI renders.
• Every image was reviewed region-by-region and approved individually by the developer before being accepted.

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16638

Devin review

---

This change is 

[andrew-polk]

[Claude Opus 5 (1M context)] Consulted Devin on 2026-07-30 16:38 USMST up to commit c5645f23bba437de7a688b7abfab8fc79159cadd.

Devin's review completed for that commit and was clean — no bugs, no Investigate flags, no informational items. Unsurprising for a change that contains no code: the diff is 22 binary reference images and the source tree is byte-identical to master.

CI (pr-automation, track / set-waiting) passed. The visual regression suite passes 12 of 12 cases at this commit, comparing all 84 images.