Make the conversation-log shrink rewrite atomic (prevent history loss on a mid-write crash) - #70

Problem

ConversationStore.save() appends new messages on the common path, but when a turn reduces the message count (context compaction / summarization) it rewrites the whole .jsonl in place:

elif len(record.messages) < existing:  # rare; not append-only
    with open(self._file(sid), "w", encoding="utf-8") as f:
        for m in record.messages:
            f.write(json.dumps(m) + "\n")

open(..., "w") truncates the file at open(), so a crash (or disk-full) partway through the rewrite leaves a truncated or empty log — permanently losing conversation history, the most valuable data the app stores. The append path is safe; only this shrink branch is non-atomic.

This is the write-side companion to #56 (tolerate a corrupt line on read). #56's per-line skip can't recover a whole-file truncation from this path — the messages are simply gone — so preventing the truncation closes the remaining gap. (#56's own note already observes that an interrupted mid-write corrupts the file.)

Fix

Write the reduced log to a temp file and Path.replace() it in one atomic step — the same tmp-then-replace pattern subscriptions.ChannelBuffer._save() already uses in this repo. os.replace is atomic on POSIX and Windows when the temp file is on the same filesystem (it is — same directory), so a concurrent reader or a crash sees either the old complete log or the new one, never a partial.

Kept intentionally minimal: the atomic rename is what fixes the truncation. I left out an fsync (power-loss durability) to match the existing ChannelBuffer idiom — happy to add it if you'd prefer.

Tests

New tests/test_conversation_atomicity.py:

• test_shrink_rewrite_preserves_history_when_write_crashes — persists a 5-message history, then simulates a crash partway through a shrink rewrite, and asserts the history survives.
  • Before the fix: FAILED — AssertionError: assert 1 == 5 (history truncated to a single message).
  • After the fix: passes.
• test_shrink_rewrite_persists_reduced_history — the normal (non-crash) shrink still writes exactly the reduced set, with no leftover temp file.

The surrounding conversation tests (autotitle, durable-resume, session-persona, attachments, memory) still pass.

This is a backend fix with no UI surface, so the "before / after" is the test result above (red FAILED assert 1 == 5 → green 2 passed) rather than a screenshot — glad to attach a terminal capture if you'd like one.