fix(state): never offer a half-written backup as a restore point

[JasonZQH]

Found by reviewing #42. A real defect in that change, on the disaster path the feature exists to protect.

The bug

sqlite3.connect creates the destination file before connection.backup() runs, and backup_ledger had no cleanup on the failure path. A backup interrupted by a full disk, an I/O error, or a killed process therefore left a 0-byte file carrying the real …-pre-migration.sqlite name.

That file is the newest, so latest_pre_migration_backup selected it and curator doctor printed it as the ledger to restore. Following that advice copies an empty database over a live ledger and destroys it.

Reproduced before fixing — a good 290KB backup on disk, then one failed attempt:

archive contains: curator-...-2-pre-migration.sqlite       0 bytes   <- failed attempt
archive contains: curator-...-pre-migration.sqlite    290816 bytes   <- the good backup
latest_pre_migration_backup -> curator-...-2-pre-migration.sqlite  0 bytes
is it the GOOD one? False

The fix

Write to a .partial name the restore glob does not match, and rename into place only once the copy completes. Rename is atomic, so an incomplete backup can never carry the real name — which also covers the killed-process case that cleanup in an except block would miss. The partial is removed on failure.

Plus one guard on the advice path: a zero-byte file is never a usable ledger, so it is skipped when choosing what to advertise. That is deliberate belt-and-braces on a code path whose output is "copy this over your live ledger".

Verification

• Two new regression tests, both confirmed to fail against the merged code and pass here (checked by stashing backup.py).
• 383 passing (381 before), ruff clean.

The other four review dimensions — CLAUDE.md adherence, git history, prior PR comments, code-comment invariants — returned no findings.

🤖 Generated with Claude Code