Zen gateway loses provider retry timing and retries 429s early #33955

Description

The Zen/Console gateway can lose provider retry timing, so OpenCode retries a rate-limited turn earlier than the provider requested.

Observed behavior: a provider rate-limit error requested a retry after approximately 37.5 seconds, while OpenCode displayed and performed a retry after 8 seconds.

Two problems exist on current dev in packages/console/app/src/routes/zen/util/handler.ts:

1. fetchWith429Retry() performs three hidden retries using fixed 500 ms / 1 s / 2 s delays and ignores upstream retry timing.
2. The response-header allowlist keeps only content-type and cache-control, stripping retry-after / retry-after-ms from the final 429.

The OpenCode client already honors both headers in packages/opencode/src/session/retry.ts when it receives them.

The observed provider also supplied retry timing inside a typed streamed error body. Because headers cannot be changed after streaming begins, that path needs the same canonical retry metadata rather than generic text-only propagation.

Expected behavior

• Provider retry timing is normalized once and preserved across both HTTP 429 and streamed-error paths.
• The gateway does not retry a 429 earlier than the normalized retry time.
• OpenCode displays and waits for that normalized delay.
• Server-side admission control protects the provider from clients that ignore retry timing.

Suggested direction

Use one canonical rate-limit error representation with retryAfterMs. Let the gateway own normalization and admission enforcement, and let OpenCode own the visible delayed retry of the model turn. Avoid independent hidden delayed retries in both layers.

Acceptance coverage

• HTTP 429 with delta-seconds Retry-After
• HTTP-date Retry-After
• retry-after-ms
• typed streamed rate-limit error carrying a retry duration
• missing or malformed retry timing