quak get and get-thumb on an empty cache stop fetching collections once they find the file (closes #222)

`quak get` and `quak get-thumb` used to wait for a refresh, which on an
empty cache fetched the files of every collection. Now, on an empty
cache, `freshFile` reads the collection list, then one collection's
files at a time, and stops at the first that holds the file. That search
stores nothing. Once the cache holds the account's collections,
`freshFile` refreshes as before and looks the file up in the cache. The
commands fetch the content through the new `Library.originalOf()` and
`Library.thumbnailOf()`, which take the file record itself, since the
store may not hold it.

On an empty cache they no longer print a refresh's progress lines. The
`-q` test that relied on `get` refreshing now runs
`helper fix-missing-thumbnails`.

Model: opus-5-5

README.md

@@ -687,12 +687,16 @@ answer, so they report current account state rather than whatever the cache last
 held. `collections` asks the server for the collection list alone, in one
 request, and neither fetches any collection's files nor changes the cache.
 `files` with a collection ID asks for the same list, then for that one
-collection's files, and does not change the cache either. The others wait for a
-refresh, and so does `files` without a collection ID. With an empty cache, as on
-a first run, that refresh fetches the files of every collection, one collection
-after another, and stores nothing until it has them all, which on a large
-account takes a while. Meanwhile the command logs a line on stderr for each
-collection whose files it has fetched, such as
+collection's files, and does not change the cache either. On an empty cache,
+`get` and `get-thumb` ask for the same list, then for one collection's files at
+a time, until they find the file. They store none of the collections or file
+records they read. The original or thumbnail they fetch is kept in the cache.
+Once the cache holds the account's collections, they wait for a refresh instead.
+The others wait for a refresh, and so does `files` without a collection ID. With
+an empty cache, as on a first run, that refresh fetches the files of every
+collection, one collection after another, and stores nothing until it has them
+all, which on a large account takes a while. Meanwhile the command logs a line
+on stderr for each collection whose files it has fetched, such as
 `Fetched the files of 3 of 120 collections`, with `--json` too; `backup` does
 the same while the refresh it starts with runs. stdout holds only the command's
 output. If that round-trip fails, the command prints the error on one line and
@@ -1187,7 +1191,8 @@ https://git.eeqj.de/sneak/quak/issues/210).
 It answers with every live file in that collection that decrypts, in the
 server's order. `collection` is a record that `freshCollections()` returned. The
 method fetches no other collection's files and stores nothing. `quak files` with
-a collection ID uses it.
+a collection ID uses it, and so do `quak get` and `quak get-thumb` on an empty
+cache.
 
 An album or file in the server's answer that quak cannot decrypt, or whose
 metadata is not JSON, does not fail the refresh. The refresh leaves it out, an
@@ -1270,6 +1275,12 @@ source. An original that `original()`, `content()` or `exif()` downloads lands
 in the cache, which does not make `isLocal` true; only `download()` and
 `lib.backup()` do.
 
+`await lib.originalOf(file, opts?)` and `await lib.thumbnailOf(file, opts?)`
+fetch and cache as `photo.original()` and `photo.thumbnail()` do. `file` is an
+`EnteFile` the caller holds, and the library need not hold it. On an empty
+cache, `quak get` and `quak get-thumb` pass one that `lib.freshFiles()`
+returned.
+
 Lower-level accessors that return decrypted model objects (which hold key
 material) are also available: `listCollections()`, `getCollection(id)`,
 `listFiles(collectionID)`, `getFile(collectionID, fileID)`, and