chore(docs): refresh blog visual baseline after content change

[wheels-bot]

Summary

A blog-content merge changed the blog index page, so the committed visual-regression baseline at web/tests/visual-baselines/blog.png is stale. Without this refresh, every subsequent web/**-touching PR fails the Visual regression check on a deterministic diff until someone refreshes manually (issue #2915).

develop's branch protection rejects direct pushes, so the refresh lands through this PR, opened and merged by the deploy run that published the blog change.

🤖 Opened automatically by .github/workflows/web-deploy.yml.

[wheels-bot]

Wheels Bot — Reviewer

TL;DR — This PR refreshes the committed visual-regression baseline at web/tests/visual-baselines/blog.png after a blog-content change (commit f902f249c, the "Pagination That Isn't a Pain" post), so subsequent web/** PRs stop failing the Visual regression check on a stale diff (issue #2915). It's an auto-generated, single-binary-file change opened by web-deploy.yml. Verdict: comment — nothing blocking; the change is structurally sound and matches its stated purpose.

Correctness

• The diff is a single binary swap of web/tests/visual-baselines/blog.png. I verified the new blob is a valid PNG of the expected dimensions (PNG image data, 1280 x 800, 8-bit/color RGB, non-interlaced, 120,615 bytes vs. the prior 128,776). The replacement is structurally well-formed and matches the baseline format the visual suite expects.
• One inherent limitation worth stating honestly: a static review can confirm the file is a valid PNG, but it cannot confirm the pixels actually correspond to the current blog index render. That verification is exactly what the Visual regression check does on the next web/** PR — so the baseline is effectively self-validating going forward. No action needed; flagging only so the "comment" verdict (vs. approve) is understood.

Commits

• chore(docs): auto-refresh blog visual baseline after content change conforms to commitlint (type chore, optional scope docs, sentence-case subject, header well under 100 chars). The PR title (chore(docs): refresh blog visual baseline after content change) is likewise a valid conventional-commit header — relevant since the repo squash-merges and the title becomes the landing subject.
• Minor: the commit carries no Signed-off-by: trailer. DCO sign-off is project policy (not a gated CI check), and this is an automation-authored PR, so this is informational rather than fix-before-merge — but worth noting if the web-deploy.yml commit step can be made to commit -s.

No tests, docs, changelog, or cross-engine concerns apply: this is test-fixture (baseline) data, not shippable code, and a chore rather than a user-facing feat/fix.