Retry rate-limited flag requests

[austinbutler]

Following my PR #251, I noticed a higher rate of 429s from LaunchDarkly's API in our CI. Makes sense, pagination means more requests.

So this PR adds retries. It's based on your own documentation for rate limiting.

I've run it in our CI for a few weeks, resulting in thousands of runs, and it handles 429s properly and the overall failure rate remains comparable to before the migration to pagination.

Please feel free to do what you want with this PR, for example if lots of changes are needed and you want to do it yourself, take whatever you want from this PR. I only want to raise the issue and ensure it gets addressed somehow.

---

Note

Overview
Replaces the paginated LaunchDarkly flag list client with a context-aware flagFetcher built on go-retryablehttp. GetAllFlags now accepts context.Context (wired from main), applies a 120s inventory timeout, and only retries HTTP 429 responses—using Retry-After, reset headers, and remaining-quota headers per LD’s rate-limiting docs, with exponential backoff when hints are missing.

Between pages it can pause proactively when responses show exhausted quota (including before switching active → archived). Failures return structured flagFetchError reasons (canceled, rate-limit deadline/exhausted, decode, etc.), avoid partial flag lists on mid-inventory errors, and surface cancellation/timeouts while reading response bodies. LD_FLAG_FETCH JSON diagnostics log start/summary, rate limits, and intended waits for CI observability.

^{Reviewed by Cursor Bugbot for commit 357fdfd. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cspath1]

@austinbutler thanks for this! I can get this merged and cut a new release for it!