Honor Retry-After for provider rate limits

[RitwijParmar]

Summary

• parse numeric and HTTP-date Retry-After headers from provider 429 responses
• use provider Retry-After as the minimum retry delay while keeping exponential backoff as the fallback
• split retry classification/delay helpers and add focused Jest coverage

Why

Provider 429s are different from 5xx failures: when a provider sends Retry-After, retrying inside that cooldown window just burns attempts and can amplify rate-limit pressure. This makes the gateway observe and respect the provider's rate-limit signal instead of treating 429 exactly like transient 5xx responses.

Fixes #5672.

Tests

• yarn workspace helicone-api test:jawn --runTestsByPath src/lib/proxy/__tests__/ProviderClient.test.ts
• yarn workspace helicone-api build

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.