Configure built-in retries across execution paths

docs/internal/capacity.md

@@ -54,32 +54,32 @@ reserve another bounded slot.
 
 ## FIFO Generation Permits
 
-`NewClient` wraps the engine's selected internal model client after public
-client adaptation or built-in client construction. Initial generation and the
-default repairer receive the same wrapper. Their requests retain the same
-effective backend, credential, numeric-presence metadata, and structured-output
-settings, so scheduling does not change provider omission semantics between
-calls.
+The engine supplies one [generation coordinator](generation.md) to initial
+generation and the default repairer. Their requests retain the same effective
+backend, credential, numeric-presence metadata, structured-output settings,
+and retry budget. Scheduling does not change provider omission semantics
+between calls.
 
-For each `Generate` call, the wrapper selects a pool from the request's
-effective backend ID. An unlimited call passes directly to the next client. A
-limited call acquires an active permit, invokes the next client, and defers
-permit release so ordinary returns and panic unwinding both restore capacity.
+For each model attempt, the coordinator selects a pool from the request's
+effective backend ID. An unlimited call uses the unrestricted path. A limited
+call acquires an active permit and defers release around that attempt, so
+ordinary returns and panic unwinding both restore capacity.
 Preparation and validation never hold an active permit.
 
 The manager's `Acquire` operation owns that active-permit acquisition and
-returns an idempotent release function. The existing wrapper delegates to it;
-the internal generation coordinator uses the same operation around individual
-attempts. There is one queue and one active limit per limited backend pool.
+returns an idempotent release function. The coordinator uses it around
+individual attempts. The earlier one-shot wrapper still delegates to the same
+operation for focused internal callers and tests, but engine assembly no
+longer uses it. There is one queue and one active limit per limited backend pool.
 
 When all active permits are occupied, calls join a mutex-protected FIFO waiter
 list. Releasing a permit transfers it directly to the oldest remaining waiter
 before making it generally available. Pools do not order work relative to
 other backend IDs.
 
-The wrapper passes generation requests, responses, and collaborator errors
-through unchanged. It owns scheduling only; the concrete model client remains
-responsible for provider transport behavior. The runner, rather than the
+The coordinator passes injected generation requests, responses, and errors
+through unchanged. The built-in HTTP client remains responsible for provider
+transport behavior. The runner, rather than the
 capacity layer, sums all five usage fields from the initial response and every
 completed repair response into the successful run result.
 
@@ -87,10 +87,10 @@ completed repair response into the successful run result.
 
 Admission checks the caller context before reserving a slot. A call canceled
 while waiting for an active permit removes its waiter under the same pool lock
-used to grant permits. If cancellation removes the waiter first, the wrapped
-client is not invoked. If a concurrent grant wins first, the call owns the
-permit and invokes the client with the original context, allowing the client
-to observe cancellation normally.
+used to grant permits. If cancellation removes the waiter first, no model
+attempt is dispatched. If a concurrent grant wins first, the call owns the
+permit; the coordinator checks the context before dispatch and releases the
+permit if cancellation has already occurred.
 
 This grant-or-cancel decision prevents lost and double-released permits.
 Admission leases and active permits are released after success, collaborator