Use VACUUM INTO for consistent database snapshots in backups

[tomcardoso]

Closes #437

Three paths copied the live, open database with plain filesystem calls while writes could be in flight, risking a torn copy: hourly auto-backup, backup:export, and settings:move-vault. A corrupt backup is discovered exactly when it's needed most.

Approach

Adds snapshotDatabase(destPath) in src/main/database/index.ts, which runs VACUUM INTO through the open connection, and routes all three call sites through it.

Note on the issue's fix sketch: it suggested db.backup(destPath) or VACUUM INTO. db.backup() does not work here — it throws backup is not supported with incompatible source and target databases on a SQLCipher database. Only VACUUM INTO is viable.

Verified empirically against the repo's native module before implementing:

• the snapshot remains fully encrypted — no plaintext SQLite header, no plaintext row data, still requires the key
• user_version is preserved (migrations depend on it)
• VACUUM INTO refuses to write to an existing path, so every call site targets a fresh temp path
• the destination is passed as a bound parameter, not interpolated — a vault folder named Tom's Backups would otherwise break or inject

Changes

• src/main/database/index.ts — new snapshotDatabase() helper
• src/main/ipc/backup.ts — fs.copyFile → snapshotDatabase (existing temp-dir plumbing reused)
• src/main/ipc/auto-backup.ts — snapshots to a temp dir, cleaned up in finally
• src/main/ipc/settings.ts — fs.cp → snapshotDatabase; corrected the comment claiming DELETE journal mode makes a live copy safe at all times (it's only safe between transactions, which is the bug)
• src/test/database-snapshot.test.ts — new; pins readability with the key, user_version preservation, the not-plaintext property, and the apostrophe-path regression

The not-plaintext assertion is the important one long-term: it guards against a future change silently producing an unencrypted backup.

Tradeoff worth knowing

VACUUM INTO is synchronous and briefly blocks the main process while it runs, where the old fs.readFile/copyFile was async. This is consistent with how the rest of the codebase does DB work on the main process, and the DB is small relative to screenshots (stored separately), but it does mean an hourly pause that scales with database size. Flagging rather than pre-optimising.

Testing

npm run typecheck clean; npm test 523 passed across 30 files.