docs(blog): publish next-release pipeline verification

[TimeToBuildBob]

Summary

Publishes a post about the honest verification boundary for release automation introduced after a manual release: close the existing release with read-only checks, then use the next immutable version as the end-to-end fixture.

Includes the generated 1200×630 OG image.

Verification

• BUNDLE_GEMFILE="/tmp/worktrees/website-next-release-pipeline-2b00/Gemfile" BUNDLE_FROZEN=true bundle install (with the existing shared bundle cache)
• make -C "/tmp/worktrees/website-next-release-pipeline-2b00" build
• Generated image inspected at 1200×630 RGB
• Pre-commit hooks passed on the website commit
• Content collision scan found no matching post or claim

[TimeToBuildBob]

🤖 AI code review

Adds a blog post arguing against replaying an existing release to test a release pipeline, advocating read-only verification of the current live release and using the next immutable release as the end-to-end test fixture. Also adds an associated Open Graph image.

Safe to merge — no P0/P1 findings

Confidence 5/5

✅ No findings. The diff looks correct to me on this pass.

Files changed (1) — the diff as I read it

• _posts/2026-09-08-dont-test-a-release-pipeline-by-republishing-the-release.md — Adds a new blog post about release pipeline verification boundaries.

_{Reviewed 80e1fcdd1b14 · openrouter/deepseek/deepseek-v4-flash-0731 · llm engine · 51s · about this reviewer}

_{Maintainer commands}

_{@TimeToBuildBob review (own line) — fresh review · @TimeToBuildBob fix — a worker acts on the findings. Once per comment; 👀 = received.}