Backup CLI: a loopback last_target should not silently route destructive offline ops to local files

[cb1kenobi]

Follow-up from #1831 review (flagged by @kriszyp on bin/backup.ts).

Context

#1831 fixed offline backup commands when a local last_target is saved: useOperationApi no longer treats a loopback last_target (localhost / 127.x / ::1) as forcing the operation-API path, so when the local server is stopped, backup commands fall back to direct file access. This fixed harper list_backups etc. failing with ECONNREFUSED after a local harper login.

Concern

A loopback last_target does not prove the endpoint is this Harper installation — it could be an SSH tunnel, a container-published port, or another local Harper root. If that endpoint is currently down and this installation's PID is absent, restore_backup / delete_backup / purge_backups now silently operate on this installation's files instead of the saved target. For destructive ops that is a footgun.

Options

• Restrict the local-last_target offline fallback to read-only ops (list_backups, verify_backup); keep destructive ops (restore/delete/purge) on the explicit path.
• Or require an explicit --offline flag (or a confirmation prompt) for destructive ops when a last_target is set but unreachable, so switching to local files is never implicit.

Ref: #1831 (commit e65940a), bin/backup.ts useOperationApi/isLocalTarget.