Memory sync and uploads now wait when the server asks them to

What

Team memory is notes Claude Code keeps and shares through a server. When the server is busy it can reply with a "retry after" signal asking the client to wait. Claude Code now respects that signal instead of treating it as a plain failure.

• Recording the wait: a new helper stores serverBackoffUntilMs from an error's retryAfterMs, and the retry-after value is carried on 429 and 503 responses.
• Skipping work: while the wait is in effect, queued uploads and deletes are skipped for that cycle with a warning, and a store logs "sitting this cycle out: the server asked sync to wait". Stores still waiting, or flagged by the pull, are skipped on push.
• Downloads: when a download hits the signal, the rest of that pull is not started ("not started after the server asked sync to wait"), and downloadsDeferred is recorded. A successful download resets downloadsDeferred.
• List requests: a list request that fails with a retry-after now reports backed_off instead of unavailable, and the error is passed on even if nothing was pulled.
• Retrying: the watcher schedules a backoff_retry sync when the wait ends, using exponential backoff (backoffRetryAtMs), even when periodic resync is disabled (interval of 0 or less). backoffRetryAtMs is cleared when a push starts.
• Results: pull and push results gain backedOff, a skipped result is added, and the sync reports pulls and pushes as backed_off rather than failed, with a stores_backed_off count.
• Batch uploader: a new cutsNextBackoff flag is reset when a drain finishes.

Separately, a tool-use summary adds a memorySave field when isMemorySaveCall matches.

Why

Before, these cases counted as ordinary pull or push failures and a stale store was only resynced on the regular interval. Now sync backs off when the server is under load and catches up on its own once the wait is over.