[SEND] Widen upload retry window: exponential backoff + jitter and an extra attempt

[mzeier]

What

Replace the upload PUT retry's fixed 1s delay with exponential backoff + jitter, and bump the retry count to give 4 total attempts (was 3), to widen the recovery window for multi-minute B2 stalls.

Why

The retry (from #679) was 3 attempts × fixed 1s delay — a ~90s window with the 30s timeout. The hard failures in Sentry SEND-SUITE-FRONTEND-24H and the storage bench (thunderbird/platform-infrastructure#274) are multi-minute B2 stalls that exceed that window (the bench saw a ~3-minute unavailability span). Bench recommendation #3 was to widen backoff before considering migration.

Changes

packages/send/frontend/src/lib/helpers.ts:

• New exported getUploadRetryDelayMs(attempt, base): delay = base * 2^attempt * (0.5 + Math.random()/2), floored so each attempt's jitter range [base*2^a*0.5, base*2^a) stays strictly below the next's — successive delays never collide (~1s, ~2s, ~4s at the 1000ms default).
• Retry loop uses the backoff schedule instead of a fixed delay.
• Retry limit 2 → 3 (4 total attempts). Both the limit and base delay are now exported, env-overridable named constants (VITE_UPLOAD_HTTP_RETRY_LIMIT, VITE_UPLOAD_HTTP_RETRY_BASE_DELAY_MS; documented in .env.sample). Note: VITE vars bake in at build, so tuning still needs a deploy — they're for tuning, not live runtime config.
• The attempt N failed, retrying... breadcrumb is preserved (now includes the delay).

Tests (helpers.retry.test.ts, helpers.test.ts):

• Assert exponential growth + jitter bounds, and strict monotonic increase of scheduled delays.
• Updated the exhausted-attempts count to 4 (via UPLOAD_HTTP_RETRY_LIMIT + 1).
• Mock setTimeout to fire on the next tick so backoff adds no wall-clock wait — the suite runs in ~0.6s instead of ~9s.

Acceptance criteria

• Retry delay grows exponentially with jitter (asserted with a mocked timer)
• Total attempts configurable; default = 4
• Existing retry tests updated and passing (21/21)
• Worst-case window documented (below)

Worst-case recovery window

4 attempts × per-attempt timeout + ~7s total backoff:

• With the current 30s timeout: ~2 min
• Once [SEND] Raise upload PUT timeout 30s -> 60s to match observed B2 stall window #910 lands the 60s timeout: ~4 min — covers the ~3 min unavailability span the bench observed.

Coordinate with

• [SEND] Raise upload PUT timeout 30s -> 60s to match observed B2 stall window #910 (timeout 30s→60s) changes per-attempt duration. This PR is independent of that change in helpers.ts (it does not touch XHR_TIMEOUT_MS), so the two won't conflict.

Refs

• Sentry: https://thunderbird.sentry.io/issues/7459337313 (SEND-SUITE-FRONTEND-24H)
• Bench rationale: thunderbird/platform-infrastructure#274
• Retry unit test precedent: test(helpers): verify HTTP retry recovers from transient 5xx (#814) #815

Closes #912

[aaspinwall]

Nice!