quak backup writes the account and album records backup-metadata writes (closes #166)

quak backup now writes account.json with the account's email and user ID,
adds each album's ownerID, isShared, updationTime and, when present, its
magicMetadata, pubMagicMetadata and sharedMagicMetadata to the album's
JSON, and adds updationTime to each file's JSON. The fields and their order
match backup-metadata's account.json, _collection.json and per-file JSON.
The interface runBackup drives gains whoami, which the library passes
through from its client.

Model: opus-5-5

README.md

@@ -599,8 +599,8 @@ the smallest does not.
                                     per unique file, two for a live photo: see
                                     below)
         YYYY-MM-DD.<fileID>.json    the file's basic metadata fields quak
-                                    keeps, its private and public magic
-                                    metadata, and its ML data
+                                    keeps, its update time, its private and
+                                    public magic metadata, and its ML data
         YYYY-MM-DD.<fileID>.livephoto.json
                                     which of a live photo's two files is which
     collections/
@@ -608,6 +608,7 @@ the smallest does not.
             <title> -> ../../YYYY/YYYY-MM/YYYY-MM-DD/YYYY-MM-DD.<fileID>.<ext>
                                     (symlink)
         <name>.json                 collection metadata + file list
+    account.json                    the account's email and user ID
     failures.json                   files that failed and have not yet succeeded
 ```
 
@@ -619,6 +620,15 @@ name as uploaded, case kept, or `.bin` when it has none or it holds anything but
 letters and digits. When the date or the time zone changes, the next run saves
 the original at its new path and leaves the old copy where it is.
 
+`account.json` holds the account's `email` and `userID`, as `backup-metadata`
+writes it. A collection's JSON holds its `id`, `name`, `type`, `ownerID`,
+`isShared` and `updationTime`, its `magicMetadata`, `pubMagicMetadata` and
+`sharedMagicMetadata` when it has them, as `backup-metadata`'s
+`_collection.json` does, and `files`, each file's `id` and `metadata`. A file's
+JSON holds its `id`, `collectionID`, `ownerID`, `metadata` and `updationTime`,
+and its `magicMetadata` and `pubMagicMetadata` when it has them. Update times
+are in microseconds, as Ente records them.
+
 A file's JSON holds Ente's ML data for it (its faces and its CLIP embedding) as
 `mlData`, the same payload `backup-metadata` writes; a file Ente has no ML data
 for has no `mlData`. The backup waits for the library's ML data fetch to finish