fix(compress): atomic filepath write to prevent data loss on crash

[d123d]

Problem

Current `compress_file` writes backup and target in sequence:

```python
backup_path.write_text(original_text)
filepath.write_text(compressed) # <-- if this raises, partial state
```

If the second `write_text` raises mid-way (disk full, permission denied, antivirus lock on Windows, OS kill), `filepath` contains a truncated/partial write OR the original — the in-memory `compressed` string proceeds to validation against `backup_path` regardless of what actually landed on disk. Worst case: validation 'passes' against a file that now contains garbage.

Same issue hits the retry-fix write (line 225) and the failure-restore write (line 216). The failure-restore is especially bad: if the restore write fails, `filepath` has the failed-validation compressed text AND the backup was already deleted — unrecoverable.

Fix

Small helper using `Path.replace()` (POSIX `rename(2)` / Windows `MoveFileEx` — atomic on same filesystem):

```python
def _atomic_write_text(target: Path, content: str) -> None:
tmp = target.with_suffix(target.suffix + ".tmp")
try:
tmp.write_text(content)
tmp.replace(target)
except Exception:
tmp.unlink(missing_ok=True)
raise
```

Invariant enforced: `target` always contains either the pre-existing content or the full new content — never a partial write.

Applied in three places:

• Initial compressed write
• Retry fix-prompt write
• Failure-restore write

Backward compat

Zero behavior change on the happy path. The `.tmp` sibling only exists during the write; `Path.replace()` is atomic. No API change.

Prior art

The project's own `hooks/caveman-config.js::safeWriteFlag` already uses temp + rename for similar reasons on the JS side. This extends the same invariant to the Python side.

Verify

```
python -m py_compile caveman-compress/scripts/compress.py
```

Passes.