docs: define analytics rate-limit states

docs/DASHBOARD-SPEC.md

@@ -32,6 +32,9 @@ Give a non-technical merchant a fast, trustworthy Persian RTL view of payment pe
 14. Later equivalent requests reuse 30-day Redis entries. PostgreSQL merchant/cohort revision changes select new cache keys and cause only missing sections to be recalculated; cache age alone does not make static data stale.
 15. SSE reconnect uses stable event ids/resume semantics, shows a connection-recovery state, and never exposes job status or analytics for another merchant.
 16. Each section attempt times out after 60 seconds. The backend may perform at most two automatic transient retries using exponential backoff/jitter; the UI represents the section as calculating during automatic retries and exposes failure/retry only after exhaustion or a non-retryable error.
+17. SSE expects a heartbeat every 15 seconds and supports authorized replay for one hour. After replay expires, the app fetches the current run snapshot before reopening the stream.
+18. Manual retry targets only one exhausted failed section. It is disabled while active, never restarts ready siblings, and handles a typed `429` by honoring `Retry-After`.
+19. Analytics starts, manual retries, and concurrent SSE connections expose accessible rate-limited states without discarding already-ready content or retrying in a tight loop.
 
 ## Frontend architecture baseline
 
@@ -56,6 +59,8 @@ Give a non-technical merchant a fast, trustworthy Persian RTL view of payment pe
 - One section failure is isolated, retryable, and accessible; already-ready sections remain usable.
 - A section does not remain indefinitely loading: each attempt is bounded to 60 seconds and no more than two automatic exponential-backoff retries occur.
 - Disconnecting and reconnecting the SSE stream resumes safely without cross-merchant data or duplicated final sections.
+- Missing heartbeats trigger controlled connection recovery; one-hour replay or snapshot fallback restores the authorized current state.
+- Rate-limited responses enqueue no duplicate work, preserve ready sections, and delay retry according to `Retry-After`.
 - Daily, weekly, Jalali-month, and Persian-season filters use the same explicit boundaries as the API and database.
 - Production build passes type checking, linting, unit/component tests, and Playwright critical-flow tests.
 - No raw dataset record, payer-card key, credential, or AvalAI key enters client bundles/logging/storage.