quak backup writes each original's EXIF, XMP and dimensions into its JSON (closes #167)

Each file's JSON gains imageMetadata, what extractImageMetadata finds in
the stored original (for a live photo, its image), or the reason the
read failed in imageMetadataError; a failed read fails neither the file
nor the run. A video is not read. An original is read when the run
stores it or when its JSON has neither field; otherwise the field is
carried over from that JSON, so a run does not read every original
again. The hand-built JPEG fixtures move to test/exif-jpeg.ts so the
backup tests can use them.

Judgement call: an original with nothing to record gets imageMetadata
{} instead of no field, so it is not read again on every run.

Model: opus-5-5

README.md

@@ -600,7 +600,8 @@ the smallest does not.
                                     below)
         YYYY-MM-DD.<fileID>.json    the file's basic metadata fields quak
                                     keeps, its update time, its private and
-                                    public magic metadata, and its ML data
+                                    public magic metadata, its ML data, and
+                                    its original's EXIF, XMP and dimensions
         YYYY-MM-DD.<fileID>.livephoto.json
                                     which of a live photo's two files is which
     collections/
@@ -637,6 +638,16 @@ not in the cache gets the reason in `mlDataError` instead and counts as failed,
 and the next run fetches it again. The JSON files are rewritten on every run, so
 ML data that arrived since the last run appears.
 
+A file's JSON holds, as `imageMetadata`, what `backup-metadata --exif` records
+from its original, or from a live photo's image: `format`, `width` and `height`
+for a JPEG, `exif` (or `exifRaw` and `exifError`), and `xmp`. An original with
+none of these gets `{}`. A video gets no `imageMetadata`: reading a whole video
+to look for tags is not worth it. When the original cannot be read, the reason
+is in `imageMetadataError` instead; neither the file nor the run fails. The
+original is read when the run stores it, or when the JSON beside it has neither
+field, as one an earlier version wrote. Otherwise the field is taken from that
+JSON when it is rewritten, so a run does not read every stored original again.
+
 `failures.json` records each failed file with the kind of failure, how many
 times it has been tried and when it was last tried. A file leaves it once it
 succeeds, or once it is no longer in the library or in the backup's scope. The
@@ -894,13 +905,14 @@ photos newest first). `lib.subscribe({ onChange })` delivers a `LibraryChange`
   `fresh()` does, puts every in-scope original not already at its save path
   there as `photo.download()` does (and, with `includeThumbnails`, fetches
   thumbnails) through the content cache, waits for an ML data fetch, and
-  rebuilds the on-disk backup tree, each file's JSON with its ML data, with a
-  durable failure ledger. A fetched original is written straight to its save
-  path and not into the cache, which then counts it as present; one the cache
-  already held is copied from there. `BackupOptions`: `downloadDirectory` (falls
-  back to the library's), `includeOriginals` (default `true`),
-  `includeThumbnails` (default `false`), `onlyAlbumNames`, and `onProgress`. See
-  Backup layout above for the tree it writes.
+  rebuilds the on-disk backup tree, each file's JSON with its ML data and its
+  original's EXIF, XMP and dimensions, with a durable failure ledger. A fetched
+  original is written straight to its save path and not into the cache, which
+  then counts it as present; one the cache already held is copied from there.
+  `BackupOptions`: `downloadDirectory` (falls back to the library's),
+  `includeOriginals` (default `true`), `includeThumbnails` (default `false`),
+  `onlyAlbumNames`, and `onProgress`. See Backup layout above for the tree it
+  writes.
 
 ### Request pools