fix(api): retry safe requests rejected by the per-user concurrency limit

[dpb97]

Fixes #338

The per-user concurrency limiter answers bursts with 429 + Retry-After: 1, but the API client surfaced that as a hard failure. On collection boards this broke the item detail fallback (six parallel reference reads via Promise.all, see f9752b0) and left pickers empty.

Change

• performFetchWithRetry() wraps performFetchAPI() in fetchFromAPI():
  • retries GET/HEAD/OPTIONS up to 2 times on 429
  • delay = Retry-After (seconds) when present, otherwise 500 ms · 2^attempt; capped at 5 s, plus up to 250 ms jitter so parallel requests spread out
  • stops waiting immediately when the caller's AbortSignal fires (keeps superseded loaders cheap)
• Writes are never retried.
• In-flight GET de-duplication is unchanged: duplicate callers share the single (retried) request.
• createApiError() now records retryAfter from the response header.

Tests

frontend/src/lib/api/core.spec.js (Vitest): retry then success, give up after the bound and surface the 429, no retry for PATCH, abort while waiting, delay calculation.
Full suite locally: 92/93 – the remaining failure (i18n-utils.spec.js > uses the active application locale, timeout) also fails on unmodified main on my machine.
biome check clean for both files.

Notes

• This deliberately lives in the API client rather than in individual stores, so every fan-out view benefits.
• Not addressed here: reducing the fan-out itself on boards (e.g. loading milestones once per board instead of per card) – happy to look at that separately.

I have read and agree to the CLA.

🤖 Generated with Claude Code

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[dpb97]

I have read the CLA Document and I hereby sign the CLA