fix(analytics): treat lazy distance-index 202 responses as transient #120

Problem

The fork's distance endpoint intentionally returns 202 Accepted with Retry-After while its lazy distance index is building (cmd/server/routes.go).

The generic frontend api() helper treats every successful 2xx response as final data and may cache it for the full analytics TTL. renderDistanceTab() then dereferences data.summary, which is absent from the 202 response. This can throw a TypeError and retain the incomplete {status:"building"} payload after the index is ready.

Upstream reference: Kpa-clawbot/CoreScope#2051.

Acceptance criteria

• Never insert a 202 response into _apiCache.
• Show a clear “building distance index” state instead of throwing.
• Honor valid Retry-After and use a bounded fallback otherwise.
• Maintain at most one retry chain per active Distance view.
• Navigation cancels or invalidates old timers and responses; an older generation cannot overwrite a newer route/tab.
• A later 200 replaces the building state and caches normally.
• Existing analytics 503 warm-up handling remains intact.

Tests

Deterministically cover 202 → 200, cache behavior, malformed/absent Retry-After, navigation away/re-entry, out-of-order generations, and absence of console errors/unhandled rejections.

Non-goals

No distance-index/backend semantic change and no deploy.