fix(blog): restore published pages when replacement fails

[rudycelekli]

Problem and change

Closes #787.

Reproduction

write_blog stages the new tree, deletes the published blog, then renames staging into place. A rename error destroys the last successful publication despite the documented atomic-write intent.

Native write_blog with committed 2026-08-08 and 2026-08-10 snapshots and actual dashboard chrome reproduces the loss when the publication rename raises OSError. Proposed scope: preserve the prior tree until the replacement succeeds, restore it when publication fails, and retain the backup if restoration itself fails. Existing test_blog.py holds the regression; no production browser dependency, source-data edits, or generated-data edits. Fresh open PR inventory has no blog.py overlap (blog shell work is a separate module).

Verification

The focused native module tests pass (46 passed). All six required commands passed at this exact SSH-signed head in a clean detached checkout with its own editable dev environment and initialized recursive submodule:

• ruff check . — passed
• ruff format --check . — passed
• benchmark-radar normalize-catalog — passed
• benchmark-radar classify — passed
• benchmark-radar build-data-release — passed
• pytest -q — passed

Full suite: 1642 passed in 89.13s (0:01:29). Regenerated catalog: 3,212 records/five sources, matching index/shard/archive identities. Python 3.12.11 and bundled Node runtime. Hosted checks are audited separately.

Prepared with AI assistance (gpt-6.1-sol), independently reviewed against native callers and regression evidence. Commit carries DCO signoff. No source-data, generated-data, or paper changes.

Publication recovery covers an OSError during replacement. This does not guarantee concurrent-writer safety or an uninterrupted atomic tree swap. Focused tests without generated site outputs skip three optional checks; the required clean sequence above runs after all generators.

[rudycelekli]

330226 gpt-6.1-sol

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ktwu01]

Closing as not planned. One author now has a cap of 10 open issues + PRs, and this account had 56 open PRs and 11 open issues, mostly paired with each other. We merged the three changes that fix silent data loss in the corpus (#723, #774, and #773 once rebased) and are closing the rest so review stays possible.

This is not a verdict that the change is wrong. If you think this one matters, reopen it later when you are under the cap, one at a time, with a reproduction from a real user or caller rather than a hypothetical edge case.

不是否定这个改动本身。为保证评审能跟上，同一作者最多同时保留 10 个未关闭的 issue/PR；该账号曾有 56 个未关闭 PR 和 11 个 issue。已合并修复语料静默丢失的三个改动，其余先关闭。若认为本条重要，请在低于上限后逐个重新打开，并附真实用户或调用方的复现。

---

Generated by Claude Code