[Feature]: Preserve callflow HTML when staging a replacement fails #4562

Problem or use case

Regenerating a callflow HTML report currently writes directly over the destination. If writing or closing the file fails after it has been opened, the previous usable report can be lost or left incomplete.

This is a source-backed improvement proposal for v8 at 86c57be8204673c2a1b9849a3292a7dd3ab373d8, not a report of a production incident. The final write in graphify/callflow_html.py uses Path.write_text.

Proposed solution

Write the rendered HTML to a temporary file before replacing the destination, using the existing text-writing helper. A handled temporary write or close failure before replacement starts should leave the previous report intact and use the helper's existing best-effort temporary-file cleanup.

Keep successful HTML content, the returned path, and CLI output unchanged on the same platform. Cover failure handling with injected write and close errors.

Alternatives considered

Exporting to a different filename preserves the old report but requires users to manage replacement themselves. Keeping the direct write leaves the same failure window.

Area

CLI or installation

Are you willing to submit a PR?

Yes, I can work on this

Compatibility / behavior impact

This concerns callflow HTML output only. It does not change graph schemas, node or edge IDs, caches, generated skills, MCP output, or incremental extraction.

Replacing a file can change its inode and hard-link behavior. Owner, ACLs, extended attributes, timestamps, and exact permissions are not guaranteed to stay the same; permission errors can also differ from an in-place write. The proposal inherits the existing helper's symlink handling and Windows fallback. It does not promise protection from power loss, process termination, or a second failure during restoration.

Additional context

The scenario is regenerating an existing report through write_callflow_html, python -m graphify.callflow_html, or graphify export callflow-html; all reach the same final writer. A controlled regression test can start with known destination bytes and inject a temporary write or close error before replacement, then verify the original bytes and temporary-file cleanup.