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 stale blog visual-regression baseline (web/tests/visual-baselines/blog.png) after the preceding blog-content commit, opened automatically by .github/workflows/web-deploy.yml (issue #2915). It is a single binary-asset change with no code, no cross-engine surface, and no security surface. Verdict: comment (clean, mechanical — nothing to block on).

Correctness

• The diff touches exactly one file, web/tests/visual-baselines/blog.png (Bin 119380 -> 119959 bytes), which is the baseline the visual-regression job compares against and the same path the workflow stages (git add web/tests/visual-baselines/blog.png, .github/workflows/web-deploy.yml:327). The drift is the expected consequence of the prior content commit 2af35e1b8 docs(web/blog): Caching in Wheels 4.0, and the workflow only commits a refreshed baseline after the regression test passes (.github/workflows/web-deploy.yml:287-291), so it cannot silently mask a genuine regression. No issue.

Commits

• chore(docs): auto-refresh blog visual baseline after content change conforms to commitlint.config.js: valid type chore, unrestricted scope docs, non-empty subject, not ALL-CAPS, header under 100 chars.

No Conventions / Cross-engine / Tests / Docs / Security findings — a binary baseline refresh has no such surface.