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

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 e65940a69), `bin/backup.ts` `useOperationApi`/`isLocalTarget`.

Start in bin/backup.ts by reading useOperationApi and isLocalTarget, then review the behavior introduced by commit e65940a69 for loopback last_target values. Confirm the intended policy between the listed options; done means unreachable loopback targets cannot silently redirect restore_backup, delete_backup, or purge_backups to local files.

Written by the indexing model from the issue text.