A backup whose only record quak cannot decrypt is an album exits 1 with
nothing in failures.json, and 0 once the album decrypts or is deleted.
The test of a file in two albums now also checks that the album where its
copy does not decrypt neither links the original nor lists the file.
Model: opus-5-5
A run of lib.backup() limited to "Trip" must store a file whose copy in
Trip does not decrypt when its copy in an album the run skips does. Today
the run neither stores it nor records it as failed.
Model: opus-5-5
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