React SPA sign-in fails with AADSTS9002326 despite registered redirect URI; misleading error guidance

[gnjoseph]

Summary

Sign-in in the scaffolded React SPA (react-spa-functions) can fail with
AADSTS9002326 (cross-origin SPA token redemption refused) even when the SPA redirect
URI is already registered on an app registration the user is looking at. The app's own
error guidance then makes this worse: it flatly asserts the failure is a server-side
missing-SPA-redirect-URI problem and "NOT a bug in this app and NOT a stale or
not-reloaded dev server" — which misdirects the user away from the actual most-common root
cause.

Repro (reported)

1. Use the MCP server to scaffold the React sample app and run it (http://localhost:5173).
2. Click Sign in.
3. Sign-in fails. The in-app guidance says to add http://localhost:5173 as a SPA redirect
   URI — but it is already on the app registration the user is viewing.
4. Token request observed at
   https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token?... returning the
   AADSTS9002326 failure.

Root-cause analysis

The error text is over-confident and points only at "add the SPA redirect URI", but the URI
was already present on the registration the user inspected. Ranked real causes:

1. Stale / mismatched provisioning state → the running build signs in as a different app
   than the one the user edited. The SPA authenticates with the VITE_CLIENT_ID /
   VITE_TENANT_ID baked into its .env at build time. If those were hydrated from stale
   or mismatched state (or .env was edited without a rebuild — Vite bakes env vars in at
   build time), the user may have added the redirect URI to a different registration than
   the one signing in. project_hydrate_config writes the values verbatim with no
   verification, and findApplicationByName returns the first match, so a duplicate
   display name can silently select the wrong app.
2. Reuse-path self-repair silently swallowed. project_app_create self-repairs a
   reused owning app by adding http://localhost:5173 to its spa.redirectUris, but the
   call is addSpaRedirectUris(..., { bestEffort: true }) and its result was discarded.
   If the signed-in identity lacks Application.ReadWrite, the add is swallowed and the app
   stays unrepaired — with no signal to the user.
3. Guest / B2B cross-tenant redemption (already advised elsewhere in the server).

Fixes in this change

• Surface the swallowed reuse-path self-repair failure (create-app.ts + new
  spa-redirect-advisory.ts): capture the addSpaRedirectUris result; when the local SPA
  redirect URI can't be confirmed on the reused app, append a non-blocking,
  copy-pasteable warning naming the exact client id + object id and the manual az rest
  PATCH/GET to self-repair. The tool still succeeds.
• Add an offline sign-in verification advisory to project_hydrate_config: append a
  persistent "verify this .env targets the right app" note to the tool output (never to
  .env) — confirm VITE_CLIENT_ID / VITE_TENANT_ID match the app in the portal Overview
  blade, and verify that exact app's spa.redirectUris via az rest GET; warn when the
  tenant id is blank (invalid MSAL authority).
• Soften the over-confident auth-error copy (auth-error-guidance.ts + its byte-for-byte
  twin in samples/react-spa-functions/src/App.tsx + the run-local sign-in note): reframe
  as "almost always an Entra app-registration configuration mismatch", and make the first
  remediation "confirm the running build's VITE_CLIENT_ID / VITE_TENANT_ID match the app
  you're viewing; rebuild if you changed .env", then keep the SPA-redirect add steps plus
  an az rest GET verification.

Also in this change

• A user-facing bug-report issue template + a lightweight skill/prompt that walks
  users through gathering the exact diagnostics needed for sign-in / AADSTS* issues
  (.env VITE_*, portal Overview client/tenant id, az rest spa.redirectUris, the exact
  AADSTS code + request URL).

Notes

The exact sub-cause for the original report can't be determined from the issue alone (needs
the reporter's .env VITE_* values vs. the portal Overview client/tenant id and that app's
spa.redirectUris). The changes above make that mismatch self-evident in tool output and
in the app's own error guidance, instead of misdirecting the user.