quak backup retries failed requests for longer (closes #165)

src/retry.ts exports UNATTENDED_RETRY_OPTIONS beside the unchanged
default: 10 attempts, a 1 s base delay and a 60 s cap, so a request that
keeps failing waits at most 243 s before it gives up. bin/quak.ts loads
the backup's session with them, so its refresh, ML data and downloads
all use them; every other command keeps the default. What is retried
and the backoff formula are unchanged.

Model: opus-5-5

README.md

@@ -430,13 +430,14 @@ instant. The numbers, configurable through `ApiClientOptions.retry`:
 
 With the defaults a file that is going to fail gives up after at most three and
 a half seconds of waiting. `quak backup` usually runs from cron with nobody
-watching, so every request it makes uses the second column instead, exported as
-`UNATTENDED_RETRY_OPTIONS`: a request that keeps failing gives up after at most
-243 seconds of waiting, and usually after about half that, since each wait is
-drawn at random below its ceiling. Every other command uses the defaults. A
-library user gets the same budget by passing `UNATTENDED_RETRY_OPTIONS` as
-`ApiClientOptions.retry`. `sleep` and `random` are injectable through the same
-option, which is how the test suite exercises the whole policy without waiting.
+watching, so every request it makes uses the `quak backup` column instead,
+exported as `UNATTENDED_RETRY_OPTIONS`: a request that keeps failing gives up
+after at most 243 seconds of waiting, and usually after about half that, since
+each wait is drawn at random below its ceiling. Every other command uses the
+defaults. A library user gets the same budget by passing
+`UNATTENDED_RETRY_OPTIONS` as `ApiClientOptions.retry`. `sleep` and `random` are
+injectable through the same option, which is how the test suite exercises the
+whole policy without waiting.
 
 Two deadlines, renewed for each attempt: