Do not prune after a backup that skipped unreadable files (closes #382)

snapshot create --skip-errors --prune pruned even when files were
skipped, so by default it deleted the previous snapshot of that name,
the only one still holding a file that had become unreadable, along
with blobs only that snapshot referenced.

The prune is now skipped exactly when the run exits non-zero for
entries --skip-errors could not read or list: older snapshots are
kept, a warning says why, and the run still exits non-zero. A file
removed during the run does not count, so such a run still prunes.
The README's --prune text and the flag's help say so.

Model: opus-5-5

README.md

@@ -297,7 +297,11 @@ value where a list belongs or a word where a number belongs), is refused.
   (for crontab)
 * `--prune`: After backup, drop older snapshots of each backed-up name and
   remove orphaned blobs from remote storage. By default keeps only the latest
-  snapshot per name; use `--keep-newer-than` for a rolling window.
+  snapshot per name; use `--keep-newer-than` for a rolling window. When
+  `--skip-errors` skipped a file or directory it could not read or list, the
+  prune does not run and every older snapshot is kept, since one of them may
+  be the only one that holds what was skipped; the command says so and exits
+  non-zero. A file removed during the backup does not stop the prune.
 * `--keep-newer-than <duration>`: With `--prune`, keep snapshots newer than
   this duration instead of only the latest (e.g. `4w`, `30d`, `6mo`, `1y`).
   Without `--prune`, or with a value that is not a valid duration, the