/**
 * Regression suite for hq-cloud production canary attempt 3.
 *
 * THE BUG
 * -------
 * The desktop DAEMON path (`runPostSyncManifestUploads` →
 * `runManifestUploadPass`) treated "the server answered" as success semantics.
 * A pass whose chunks were all accepted but whose fold the server refused
 * (`materialised: false` — what a KMS `AccessDenied` in hq-pro's upload Lambda
 * produces) was recorded with `lastUploadAt`, which:
 *
 *   - armed the FULL 24h throttle on the very first failure, with no
 *     escalation to grow out of;
 *   - cleared `lastAttemptAt`/`consecutiveFailures`, erasing the escalation
 *     state entirely;
 *   - and was reported to the daemon as `status: "uploaded"`, so the ndjson
 *     event stream, the desktop app and `hq doctor` all read healthy.
 *
 * The record left on the operator's machine is checked in verbatim at
 * `test/fixtures/manifest-canary/personal-throttled-on-500.json`.
 *
 * Everything here drives the REAL `runManifestUploadPass` through the REAL
 * runner tail step. A stubbed `runPass` cannot see this bug: the divergence was
 * never in the runner's own branching, it was in which bookkeeping function the
 * seam picked, and the runner is what makes it a production incident by
 * reporting the result as a clean upload.
 */
export {};
//# sourceMappingURL=sync-runner-backoff.regression.test.d.ts.map