Parse a RateLimit-Reset header into a delay in milliseconds. The Routing API
documents it (routing-api.yaml) as the backoff signal of a 429 — "Auswertung
der RateLimit-Headers erforderlich" — and sends no Retry-After. Its spec calls
the value "the point in time, in seconds, at which the current window ends",
which reads as either delta-seconds (the IETF RateLimit draft) or a Unix
timestamp, so both are accepted: digits only; a value of at least 10^9 is a
timestamp (time left from now, 0 if past), a smaller one delta-seconds.
Anything else ("-1", "1.5", a date) → undefined, as in parseRetryAfter.
The engine uses it only when there is no usable Retry-After, with the same
MAX_RETRY_AFTER_MS rule.
Parse a
RateLimit-Resetheader into a delay in milliseconds. The Routing API documents it (routing-api.yaml) as the backoff signal of a 429 — "Auswertung der RateLimit-Headers erforderlich" — and sends noRetry-After. Its spec calls the value "the point in time, in seconds, at which the current window ends", which reads as either delta-seconds (the IETF RateLimit draft) or a Unix timestamp, so both are accepted: digits only; a value of at least 10^9 is a timestamp (time left fromnow, 0 if past), a smaller one delta-seconds. Anything else ("-1","1.5", a date) →undefined, as inparseRetryAfter. The engine uses it only when there is no usableRetry-After, with the sameMAX_RETRY_AFTER_MSrule.