Deployment issue: Lack of Cheap Admission Control and Adaptive Retry-After with Exponential Backoff

## Overview

During deployment events, stack transitions, or high-load scenarios, the current admission control and retry behavior can lead to thundering herd problems and suboptimal recovery. This parent issue tracks improvements to make admission control cheaper (shed load earlier) and retry behavior adaptive (server and client coordinate via `Retry-After`).

## Problem

**Server side:**
- Admission control runs too late in the request pipeline and is computationally expensive under load
- `Retry-After` values are hardcoded in multiple places with no adaptation to actual load or recovery state
- When many requests arrive simultaneously, bottlenecks form before admission control can shed load

**Client side:**
- Elixir client ignores `Retry-After` headers entirely on 503 responses
- TypeScript client honors `Retry-After` but adds no jitter when server delay dominates client backoff, causing synchronized retries
- Some error paths retry immediately with no backoff delay

## Goal

1. **Cheap admission control** — shed load as early as possible in the request pipeline with minimal per-request cost
2. **Adaptive Retry-After** — server returns dynamic values based on load/recovery state rather than fixed constants
3. **Well-behaved clients** — all clients honor `Retry-After`, add jitter to prevent synchronized retries