Multiple static Retry-After values throughout the codebase

[alco]

Problem

Retry-After is currently calculated in several separate places in packages/sync-service, mostly as fixed values. This makes retry behavior inconsistent and prevents the server from adapting during overload, redeploy, or stack transition events.

This is especially risky because the TypeScript client treats server Retry-After as a floor and combines it with client-side jitter. A fixed server value like 10 can dominate early client backoff attempts and cause many clients to retry together.

Current call sites

• lib/electric/plug/serve_shape_plug.ex
  • DB connection errors set retry-after: 10 directly.
  • admission-control overload calls a private calculate_retry_after/2, currently random 6..10 seconds.
• lib/electric/shapes/api.ex
  • shape creation failure: retry_after: 1
  • stack not ready after timeout: retry_after: 5
  • snapshot creation errors: retry_after: 10
  • long-poll timeout while stack is not up/read-only: retry_after: 10
• lib/electric/shapes/api/params.ex
  • DB unavailable while validating shape params: retry_after: 1
• lib/electric/shapes/api/response.ex
  • only serializes the value into the retry-after header and exposes it via CORS; this should likely remain a dumb response-layer concern.

AdmissionControl already owns the core overload decision, per-stack/per-kind counters, and reject telemetry, but it currently returns only {:error, :overloaded}. The caller then invents the retry delay locally.

Proposal

Centralize Retry-After calculation in logic rooted in Electric.AdmissionControl.

For admission overloads, try_acquire/3 should either return retry metadata, e.g. {:error, {:overloaded, retry_after}}, or expose a central helper that callers use immediately after rejection.

The retry policy should use exponential backoff with jitter, keyed by overload context such as:

• stack_id
• request kind: :initial or :existing
• reason: admission overload, stack not ready, DB unavailable, snapshot pressure, etc.

Suggested behavior:

• use jitter for every transient 503
• increase delays under sustained rejection/overload
• reset or decay the backoff when capacity recovers
• cap the initial implementation, e.g. at 120s
• keep Cache-Control: no-store and Surrogate-Control: no-store on transient overload responses
• emit telemetry including retry_after, reason, kind, current count, limit, and rejection/backoff state

Other transient 503 paths should call the same policy instead of hard-coding 1, 5, or 10.

Acceptance criteria

• No hard-coded sync-service transient Retry-After values remain in request handling paths.
• Admission-control rejection responses get Retry-After from the central policy.
• The policy has unit coverage for exponential growth, jitter bounds, cap behavior, and reset/decay.
• Router/API tests assert policy behavior rather than specific static values.
• Docs that mention fixed Retry-After values are updated if the public behavior changes.

Open questions

• Should the exponential “attempt” be server-side overload streak state, client-provided attempt metadata, or a hybrid?
• Should DB unavailable, stack not ready, and snapshot pressure share one policy with different baselines, or use separate reason-specific profiles?