Self-heal stale local_path pointers on read

Backups completed before the keep-local-backups feature never had
local_path nulled out after the local archive was deleted, so the new
"Local copy: Kept" indicator was trusting a stale DB column instead of
reality. GET /api/backups and GET /api/backups/{id} now verify the
file still exists and clear local_path if it doesn't, which also
covers any future case of a local file disappearing outside the app.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -125,6 +125,7 @@ Important behavior:
 - Retention runs after backup completion and hourly from the worker.
 - A completed backup whose local archive is missing (never kept, or deleted via "Delete local copy") can be re-fetched from the remote into `local_backup_dir` via `POST /api/backups/{id}/download`; this is a transient `local_downloading` state that resumes on worker restart. Since `local_backup_dir` is the actual Proxmox storage dump directory, a downloaded archive shows up in the Proxmox UI for the operator to restore from directly — this app never runs the restore itself.
 - A locally-retained (or downloaded) copy can be removed independently of the remote object via `DELETE /api/backups/{id}/local`, without affecting `state` or `remote_path`.
+- `local_path` is not trusted blindly: `GET /api/backups` and `GET /api/backups/{id}` verify the file still exists on disk and clear `local_path` in SQLite if it doesn't, so a stale pointer (e.g. left over from a version that didn't null it, or a file removed outside the app) never shows as "kept" in the UI.
 
 ## Applying updates after pulling changes