PART3: feat(settings): Migrate fxa-settings from GraphQL to direct auth-client (cutover)

[vbudhram]

Because

• The fxa-graphql-api service adds unnecessary latency and complexity between fxa-settings and fxa-auth-server
• GraphQL mutations/queries coupled the frontend to Apollo cache management, making state management harder to reason about
• Direct auth-client calls simplify the data flow and reduce the dependency surface

This pull request

• Removes ApolloProvider, ApolloClient, and all GQL mutations/queries from the fxa-settings entrypoint and page containers
• Replaces GQL calls with direct fxa-auth-client methods (signInWithAuthPW, getCredentialStatusV2,
  sendUnblockCode, etc.)
• Adds account-storage.ts — unified localStorage-based account state replacing the Apollo InMemoryCache
• Adds AccountStateContext and
  AuthStateContext React contexts for reactive state management
• Adds useAccountData hook that fetches account, profile, and attached clients data in parallel via auth-client
• Renames gql-key-stretch-upgrade to auth-key-stretch-upgrade, now calling auth-client directly
• Replaces Apollo cache with a no-op shim for remaining legacy references (gql.ts)
• Removes @apollo/client and graphql from fxa-settings dependencies
• Removes PageMfaGuardWithGqlTest (GQL-only test page)
• Updates all Signin, Signup, InlineTotpSetup, and InlineRecoverySetup containers and their tests

Issue

Closes: https://mozilla-hub.atlassian.net/browse/FXA-12995

Checklist

• My commit is GPG signed
• Tests pass locally (if applicable)
• Documentation updated (if applicable)
• RTL rendering verified (if UI changed)

Other Information

Scope: 90 files changed, ~2,600 insertions, ~2,700 deletions

Breaking changes: The fxa-graphql-api server is no longer required for fxa-settings to function. CSP rules for the GQL endpoint have been removed from content-server configuration.

Legacy shim: gql.ts and cache.ts retain a no-op Apollo cache shim for files not yet migrated (PostVerify, SetPassword, InlineRecoveryKeySetup). These should be cleaned up in a follow-up.

[dschom]

Why do we have to do this? It seems like in a fucntional tests stuff like this shouldn't be needed.

[vbudhram]

Yea, this was surprising to me. Wit the graphql removal, these started to fail, however they were not structured the same way as the other tests which did do this. Its possible that our graphql approach was masking something.

[dschom]

Have we manually tested this flow? A user won't be able to trigger that respondToWebChannelMessage call, which makes me question if this actually works or we lost something important in the migration.

[vbudhram]

Tested this locally and the signin/up works as expected, no hanging.

[dschom]

Let's give it a go! Thanks for all these changes. R+WC

I think this one is still a little funny. We could investigate in a follow up though.

And it seems like we should still remove this to ensures calls stick to the defined types.