One album or file quak cannot decrypt no longer stops a refresh or a backup (closes #181)

collectionsSince and filesSince put a row that does not decrypt or parse in
an undecryptable list with the reason instead of throwing. The refresh
leaves it out, an album with its files, and the store keeps the list in
metadata.json until the server sends a copy that decrypts or deletes it,
since the next refresh asks only for changes. lib.backup() records each
such file in failures.json as "could not be decrypted: <reason>", unless a
copy in another album decrypted, logs one line per such album and lists
their IDs in undecryptableAlbums; quak backup exits 1 while any remain.
Tests use a stand-in Ente server with real encryption.

Model: opus-5-5

TODO.md

@@ -25,6 +25,17 @@ declares one.
 
 # Completed Steps
 
+- 2026-10-13: An album or file quak cannot decrypt, or whose metadata is not
+  JSON, no longer fails the refresh, so one bad record no longer stops
+  `quak backup` from storing anything (issue 181). The refresh leaves it out, an
+  album with its files, and the library keeps it with the reason in
+  `metadata.json` until the server sends a copy that decrypts or deletes it. The
+  backup stores every other file, records each such file in `failures.json` with
+  an error starting `could not be decrypted:`, prints one line naming each such
+  album's ID, lists those IDs in `undecryptableAlbums`, and exits 1 while any
+  remain. A file whose copy in another album decrypts is backed up as usual. The
+  read commands answer from what decrypted.
+
 - 2026-10-14: `test/cli/backup-end-to-end.test.ts` runs `quak backup` as cron
   does (issue 186): `backupCommand` and `run`, the real `loadSession` reading a
   session saved after logging in, and every request answered by a fake of the