fix(config-backup): reuse the newest backup as the undo copy when nothing changed

Merge-time fix for #661. The pre-restore copy was forced, so a restore made
while the live files equalled the newest backup spent a retention slot on a
duplicate. It now goes through the normal change check: when nothing changed
since the newest backup, no copy is made and safetySnapshot names that
backup. Two tests that relied on the forced copy now change a file before the
restore; a new one pins the reuse.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/api-reference.md

@@ -1165,7 +1165,7 @@ Settings (synced, in `settings.json`): `configBackupEnabled` (absent = on), `con
 | `GET`  | `/api/config-backups`                | none | `settings` in effect, `dir`, `defaultDir`, `tracked[]` and `backups[]` (`id`, `createdAt`, `reason`, `appVersion`, `files[]`, `bytes`), newest first.                                                                                                                                                                                                                                                                  |
 | `POST` | `/api/config-backups`                | none | Snapshot now, even if nothing changed (`reason: manual`), then apply retention. `status` is `created` or `empty` (nothing tracked exists yet); `removed[]` lists the ids retention deleted. `503` when a custom folder does not answer.                                                                                                                                                                                                                                                                         |
 | `GET`  | `/api/config-backups/diff?from=&to=` | none | What differs between two states: `from`/`to` are a backup id or `current` (the running config; the default for `to`). `files[]` (`name`, `status` `added`/`removed`/`changed`/`unchanged`, `changes[]` of `path`, `kind`, `before`/`after`, `truncated`, `detail`) and `changed`. Credential values are never returned (`redacted: true`). `400` without `from`; `404` unknown id; `409` if a file fails its checksum. |
-| `POST` | `/api/config-backups/:id/restore`    | none | Put a snapshot's files back, atomically, after a `pre-restore` snapshot of the current ones. `404` unknown id; `409 CONFLICT` if a file fails its checksum (nothing changed). Returns `restored[]`, `untouched[]` (tracked files present now that the backup did not hold; left as they are), `safetySnapshot` (the `pre-restore` id) and `restartRequired[]` (files the running server only reads at start: `.env`, `push-keys.json`, `settings.json`). A file that cannot be written (a full disk, a directory in its place) does not stop the others: the answer is then `500 OPERATION_FAILED` with the same fields in `data` plus `failed[]` (`name`, `error`); the files listed in `restored[]` are the backup's and are reloaded like a full restore.                                                                                                                                                              |
+| `POST` | `/api/config-backups/:id/restore`    | none | Put a snapshot's files back, atomically, after a `pre-restore` snapshot of the current ones (none when nothing changed since the newest backup). `404` unknown id; `409 CONFLICT` if a file fails its checksum (nothing changed). Returns `restored[]`, `untouched[]` (tracked files present now that the backup did not hold; left as they are), `safetySnapshot` (the `pre-restore` id, or the newest backup's when nothing had changed since it) and `restartRequired[]` (files the running server only reads at start: `.env`, `push-keys.json`, `settings.json`). A file that cannot be written (a full disk, a directory in its place) does not stop the others: the answer is then `500 OPERATION_FAILED` with the same fields in `data` plus `failed[]` (`name`, `error`); the files listed in `restored[]` are the backup's and are reloaded like a full restore.                                                                                                                                                              |
 
 ## Webhook notifications
 

docs/wiki/Config-Backups.md

@@ -48,7 +48,8 @@ cron jobs.
   `intents.json` as unchanged when only prompts differ, yet a restore drops the prompts captured
   since.
 - **On demand**, with **Back up now** (always writes one, even if nothing changed).
-- **Before a restore**, as a `pre-restore` safety copy of the files about to be replaced.
+- **Before a restore**, as a `pre-restore` safety copy of the files about to be replaced (unless
+  nothing changed since the newest backup).
 
 ## Where they go and what they are called
 
@@ -132,16 +133,17 @@ From the list, press **Restore** on a backup and confirm. Codeman then:
    mode for every file, so it would refuse every backup there). The symlink test is not. Compare
    applies the same checks to the backups it reads.
 2. **Takes a `pre-restore` backup** of the files about to be replaced, so a restore can itself
-   be undone.
+   be undone. When nothing changed since the newest backup (the same comparison an automatic
+   backup makes), no copy is made and the response names that backup instead (`safetySnapshot`).
 3. **Replaces each file atomically** (written beside it, then renamed) with mode `0600`.
 
 Only the tracked names are ever written, whatever a manifest lists.
 
 If a file cannot be written (a full disk, a folder where the file should be), the restore still
 writes the others and then reports an error that names the files it restored, the ones it could
-not write, and the `pre-restore` backup that holds the files as they were before. The restored
-files are in effect as after a full restore (Settings re-reads `settings.json` into the form), so
-fix the cause and restore again, or restore the `pre-restore` backup to go back.
+not write, and the backup that holds the files as they were before. The restored files are in
+effect as after a full restore (Settings re-reads `settings.json` into the form), so fix the cause
+and restore again, or restore that backup to go back.
 
 Restoring `settings.json` keeps the four backup settings (on or off, folder, how many, how many
 days) at their current values, so a restore from before a folder change does not point the list