…r-info toast

Two related UX fixes following #6214:

1. ClusterAssignmentPanel — Active Clusters picker showed every kubeconfig
   context, not every distinct cluster. Multiple OpenShift contexts pointing
   at the same API server (one per user identity) produced duplicate rows
   like '[email protected]' x4. Switch to deduplicatedClusters from
   useClusters() so contexts pointing at the same server collapse into a
   single picker entry — this is the same dedupe used everywhere else for
   metrics and stats per the project-wide rule.

2. AuthCallback — the 'Failed to fetch user info, proceeding anyway' warning
   toast was appearing even when login succeeded. Two causes, both fixed:
   - StrictMode double-mount race: the cleanup ran before the catch fired,
     so the navigate-to-login was cancelled but the toast was already shown.
     Add a 'cancelled' flag and bail out of the catch handler when the
     component has unmounted.
   - Token-exchange-succeeded race: setToken ran successfully but the
     follow-up refreshUser(token) call failed (e.g. transient network
     blip). The user is authenticated and sees their username, but the
     catch block was firing the misleading warning toast and scheduling
     a navigate-back-to-login that the auth context's own navigation
     usually overrode. Track tokenExchangeSucceeded and proceed silently
     to the destination on a post-token failure rather than warning + bouncing.
   Also clear the abort timeout in cleanup to avoid a stale abort during
   StrictMode double-mount, and use a lazy initial useState for status to
   satisfy react-hooks/set-state-in-effect.

Signed-off-by: Andrew Anderson <[email protected]>

…r-info toast (#6223)

Two related UX fixes following #6214:

1. ClusterAssignmentPanel — Active Clusters picker showed every kubeconfig
   context, not every distinct cluster. Multiple OpenShift contexts pointing
   at the same API server (one per user identity) produced duplicate rows
   like '[email protected]' x4. Switch to deduplicatedClusters from
   useClusters() so contexts pointing at the same server collapse into a
   single picker entry — this is the same dedupe used everywhere else for
   metrics and stats per the project-wide rule.

2. AuthCallback — the 'Failed to fetch user info, proceeding anyway' warning
   toast was appearing even when login succeeded. Two causes, both fixed:
   - StrictMode double-mount race: the cleanup ran before the catch fired,
     so the navigate-to-login was cancelled but the toast was already shown.
     Add a 'cancelled' flag and bail out of the catch handler when the
     component has unmounted.
   - Token-exchange-succeeded race: setToken ran successfully but the
     follow-up refreshUser(token) call failed (e.g. transient network
     blip). The user is authenticated and sees their username, but the
     catch block was firing the misleading warning toast and scheduling
     a navigate-back-to-login that the auth context's own navigation
     usually overrode. Track tokenExchangeSucceeded and proceed silently
     to the destination on a post-token failure rather than warning + bouncing.
   Also clear the abort timeout in cleanup to avoid a stale abort during
   StrictMode double-mount, and use a lazy initial useState for status to
   satisfy react-hooks/set-state-in-effect.

Signed-off-by: Andrew Anderson <[email protected]>

The GitHub Search API caps results at 1000 per query, which meant the
live /api/analytics-accm endpoint couldn't reach more than the most
recent ~12 weeks of kubestellar/console history (busy weeks alone
exceed the cap). The Analytics page showed mostly empty bars for
early weeks even after #6214 removed the 12-week rolling window.

Fix: precompute the full dataset out-of-band and serve it from a
public gist.

1. scripts/build-accm-history.mjs — Node script that slices the
   search by 7-day windows so no single query approaches the 1000-
   result cap, paginates with retry-on-rate-limit, and emits the
   same ACCMData shape the Netlify Function returns.

2. .github/workflows/accm-history-update.yml — daily cron (06:30 UTC)
   that runs the script and PATCHes the public gist
   (21a665e2a49ced34f83bc290c3fd6a23). Also wired for manual dispatch.
   Requires a new secret ACCM_HISTORY_GIST_TOKEN (PAT with 'gist' scope)
   — the default GITHUB_TOKEN cannot write to gists.

3. web/netlify/functions/analytics-accm.mts — try the gist first; fall
   back to live computation on any failure so the endpoint stays
   available even if the gist or the cron breaks. Also corrects
   PROJECT_START_DATE to 2026-01-16 (verified via repos/created_at).

Initial gist seed verified locally: 13 weeks, 3626 PRs (97.4% AI),
2600 issues, 39 contributors, from 2026-W03 through 2026-W15.

Signed-off-by: Andrew Anderson <[email protected]>

The GitHub Search API caps results at 1000 per query, which meant the
live /api/analytics-accm endpoint couldn't reach more than the most
recent ~12 weeks of kubestellar/console history (busy weeks alone
exceed the cap). The Analytics page showed mostly empty bars for
early weeks even after #6214 removed the 12-week rolling window.

Fix: precompute the full dataset out-of-band and serve it from a
public gist.

1. scripts/build-accm-history.mjs — Node script that slices the
   search by 7-day windows so no single query approaches the 1000-
   result cap, paginates with retry-on-rate-limit, and emits the
   same ACCMData shape the Netlify Function returns.

2. .github/workflows/accm-history-update.yml — daily cron (06:30 UTC)
   that runs the script and PATCHes the public gist
   (21a665e2a49ced34f83bc290c3fd6a23). Also wired for manual dispatch.
   Requires a new secret ACCM_HISTORY_GIST_TOKEN (PAT with 'gist' scope)
   — the default GITHUB_TOKEN cannot write to gists.

3. web/netlify/functions/analytics-accm.mts — try the gist first; fall
   back to live computation on any failure so the endpoint stays
   available even if the gist or the cron breaks. Also corrects
   PROJECT_START_DATE to 2026-01-16 (verified via repos/created_at).

Initial gist seed verified locally: 13 weeks, 3626 PRs (97.4% AI),
2600 issues, 39 contributors, from 2026-W03 through 2026-W15.

Signed-off-by: Andrew Anderson <[email protected]>

…, single cache read (#6212, #6220)

#6212 — Copilot review on #6207 (README round 4)
==================================================
Two factual errors caught against source.

1) The README treated 'GitHub PAT in Settings UI' and
   'FEEDBACK_GITHUB_TOKEN' as separate, 'not interchangeable'
   credentials. Wrong — verified against
   pkg/api/handlers/github_proxy.go:92 and :238: both write to the
   single FeedbackGitHubToken field on AllSettings, which is consumed
   by the github proxy, feedback issue creation, missions, and
   rewards. They are TWO WAYS TO SUPPLY THE SAME TOKEN, not separate
   credentials. Merged the table rows into one 'Consolidated GitHub
   PAT' row and added a 'Setting the consolidated PAT' subsection
   that explains the env-var path and the Settings UI path are
   equivalent — pick one.

2) The Settings UI POST /api/github/token endpoint requires the
   console 'admin' role and returns 403 otherwise. Verified at
   pkg/api/handlers/github_proxy.go:214:
     if currentUser.Role != "admin" { return 403 }
   The README implied any self-hosted user could persist the PAT.
   Documented the admin requirement explicitly in the new section.

#6220 — Copilot review on #6214 (analytics + cache)
=====================================================
Two small correctness fixes.

1) web/public/analytics.js:957 — KPI percentages for Human PRs/Issues
   were computed as `100 - aiPct`. With totalPrs===0, aiPct is forced
   to 0, so the Human KPI rendered as 100% with the change line
   '0 of 0 PRs' — extremely confusing. New humanPrPct/humanIssuePct
   variables that also force to 0 in the empty case, so both KPIs
   render as 0% / 0% / '0 of 0' when there is no data.

2) web/src/hooks/useMediumBlog.ts:78-82 — readCache() was called THREE
   times during initial render (one per useState lazy initializer),
   repeating sessionStorage.getItem + JSON.parse three times and
   creating a tiny race window if the cache changed between calls.
   Read once into a captured initialCache variable; all three
   useStates derive from the same snapshot.

Verified: `npm run build` clean.

Closes #6212, closes #6220.

Signed-off-by: Andrew Anderson <[email protected]>

…, single cache read (#6212, #6220) (#6236)

#6212 — Copilot review on #6207 (README round 4)
==================================================
Two factual errors caught against source.

1) The README treated 'GitHub PAT in Settings UI' and
   'FEEDBACK_GITHUB_TOKEN' as separate, 'not interchangeable'
   credentials. Wrong — verified against
   pkg/api/handlers/github_proxy.go:92 and :238: both write to the
   single FeedbackGitHubToken field on AllSettings, which is consumed
   by the github proxy, feedback issue creation, missions, and
   rewards. They are TWO WAYS TO SUPPLY THE SAME TOKEN, not separate
   credentials. Merged the table rows into one 'Consolidated GitHub
   PAT' row and added a 'Setting the consolidated PAT' subsection
   that explains the env-var path and the Settings UI path are
   equivalent — pick one.

2) The Settings UI POST /api/github/token endpoint requires the
   console 'admin' role and returns 403 otherwise. Verified at
   pkg/api/handlers/github_proxy.go:214:
     if currentUser.Role != "admin" { return 403 }
   The README implied any self-hosted user could persist the PAT.
   Documented the admin requirement explicitly in the new section.

#6220 — Copilot review on #6214 (analytics + cache)
=====================================================
Two small correctness fixes.

1) web/public/analytics.js:957 — KPI percentages for Human PRs/Issues
   were computed as `100 - aiPct`. With totalPrs===0, aiPct is forced
   to 0, so the Human KPI rendered as 100% with the change line
   '0 of 0 PRs' — extremely confusing. New humanPrPct/humanIssuePct
   variables that also force to 0 in the empty case, so both KPIs
   render as 0% / 0% / '0 of 0' when there is no data.

2) web/src/hooks/useMediumBlog.ts:78-82 — readCache() was called THREE
   times during initial render (one per useState lazy initializer),
   repeating sessionStorage.getItem + JSON.parse three times and
   creating a tiny race window if the cache changed between calls.
   Read once into a captured initialCache variable; all three
   useStates derive from the same snapshot.

Verified: `npm run build` clean.

Closes #6212, closes #6220.

Signed-off-by: Andrew Anderson <[email protected]>