Bring README and TODO.md in line with next after the milestone merge (closes #132)

README.md and TODO.md were read end to end against the code after the milestone merge, and every sentence the code contradicted was corrected. The corrections cover the login and key-derivation steps (the TOTP step, email OTP, the SRP library), retries and download staging, which CLI commands take which options, which of each file's metadata the backup keeps, how default and fresh reads behave, the cache options, and what the tests cover. TODO.md's next step now says no implementation work is open and the cache design waits on sneak.

Docs only.
Left as written: the development workflow's `main` base, a process question.
Merged under the docs-only rule after four reviews; the fix for the fourth review's one finding was not re-reviewed.

Model: opus-5-5

TODO.md

@@ -14,13 +14,43 @@ pre-1.0
 
 # Next Step
 
-None: every issue still open is done on `next` and waits for it to reach `main`.
+None: no implementation work is open. The cache design,
+https://git.eeqj.de/sneak/quak/issues/36, waits on sneak's review.
 
 Tagging and releases are decided by sneak alone, and happen only when he
 declares one.
 
 # Completed Steps
 
+- 2026-09-29: Brought the README and this file in line with `next` after the
+  milestone merge (issue 132). The Next Step says no implementation work is open
+  and the cache design (issue 36) waits on sneak's review. README corrections:
+  the Getting Started comments say when the library refreshes; most, not all,
+  Makefile targets call a script; `script/lint` and `script/test` have no host
+  path, though `yarn test` does; the SRP handshake uses `fast-srp-hap`, outside
+  `crypto/`, and a thumbnail upload's MD5 uses `node:crypto`; the SRP password
+  is the first 16 bytes of a 32-byte subkey; the key attributes and token come
+  after SRP, after the TOTP code SRP may ask for, or after the email OTP that
+  replaces SRP when the account has email MFA on, and quak cannot answer a
+  passkey; the auth token is sent as URL-safe base64 with padding; every
+  `TypeError` is retried; each download attempt writes its own temporary files,
+  two for a live photo, and only the attempt that completes renames them into
+  place; `runMetadataBackup` records a failed download in the file's JSON; a
+  second `client.logout()` does not throw; `quak logout` with no session exits
+  0, and names the cache directory only when it knows it; `login`, `whoami` and
+  `logout` open no library; `--exif` records XMP and, for a JPEG, EXIF, and no
+  IPTC; which commands take `--json`; a failed ML data request may not have been
+  retried; the thumbnail fixer is not limited to baseline JPEG; `quak backup`
+  still fetches ML data; a backup's JSON holds the basic metadata fields quak
+  keeps and the private and public magic metadata, not every decrypted field,
+  and the README no longer lists what the magic metadata holds; the default
+  cache directory is the per-user one, not an XDG path on macOS; pinned
+  originals can exceed `cacheOriginalsMaxBytes`; which tests cover which
+  operations; a default read is only as current as the last refresh whose
+  requests all succeeded; `fresh()` and `lib.backup()` join a refresh already
+  running; a `Photo` has no `thumbnailPath` or `originalPath`; and `408` and
+  `429` are retried.
+
 - 2026-09-28: Tested the live-photo writer's fsyncs (issue 130). A test checks
   that the image's and the video's temp files are fsynced before either is
   renamed into place, and the directory after both renames, as the `writeAtomic`