Frontend treats 429 from the per-user concurrency limiter as a hard failure #338

Summary

The per-user concurrency limiter (internal/middleware/user_concurrency.go, default MAX_USER_CONCURRENCY=16) rejects request bursts with 429 Too Many Requests and Retry-After: 1. The API client (frontend/src/lib/api/core.js) does not retry these, so views that fan out many reads at once fail intermittently even though the server explicitly asks the client to retry a second later.

Where it shows up

• Collection boards (/collections/{id}/board): many cards trigger parallel reads (e.g. MilestoneCombobox), plus workspaceDataStore.initializeGlobal(). Console:

  WorkspaceDataStore: global initialization failed Error: Too many concurrent requests
  Failed to load milestones: Error: Too many concurrent requests
  

• Item detail opened from a collection board: since f9752b0 the fallback path hydrates six reference lists with Promise.all. If any one of them gets a 429, the whole modal shows "Too many concurrent requests" instead of the item.
• It gets much more frequent with a slower database (longer in-flight requests) – we hit it constantly on a small Azure PostgreSQL Flexible Server (B1ms) and still occasionally on B2s.

Expected

Safe requests rejected by the limiter are retried after Retry-After, so a short burst degrades to a small delay instead of an error.

Environment

main @ 5832187 (also v0.8.9), Docker image, PostgreSQL 16 (Azure Flexible Server), single replica, default MAX_USER_CONCURRENCY.

I have a small PR ready that adds a bounded retry for GET/HEAD/OPTIONS in core.js.