fix(transport): jittered backoff for API rate limits

[Spazzy757]

Background

We hit sustained HTTP 429 rate limiting from the Scaleway API when applying with Terraform's default concurrency.

While diagnosing, I captured a real 429 from the Scaleway API by bursting concurrent read-only requests:

HTTP/2 429
x-envoy-ratelimited: true
server: Scaleway API Gateway (fr-par-3;edge03)

Scaleway's API Gateway is Envoy-based, and its rate-limit filter returns a bare 429 with no timing guidance at all — no Retry-After, no X-RateLimit-* headers. So header-driven backoff cannot help here; client-side backoff is the only lever.

Problem

The retry transport left go-retryablehttp's DefaultBackoff in place. Its fallback exponential backoff has no jitter. Under Terraform's concurrent execution (default -parallelism=10), every throttled request backs off in lock-step (2s → 4s → 8s …) and retries at the same instant — a thundering herd that immediately re-triggers the limit.

Change

• Replace the backoff with a jittered exponential strategy (full jitter across [min, min*2^n], capped at RetryWaitMax), wired via Client.Backoff. This spreads concurrent retries out and breaks the herd.
• Raise RetryMax from 3 to 5 so sustained throttling gets more attempts.
• Retry-After is still honored when present (standard, zero cost) in case an individual product API sets it — though the gateway does not.
• Add unit tests covering Retry-After parsing, jitter bounds/variance, the x-envoy-ratelimited fallback path, the RetryWaitMax cap, and zero-min safety.

go build, go vet, gofmt, and the transport tests all pass.

🤖 Generated with Claude Code