Support new Firefox webchannel message to resume login

[vbudhram]

Because

• Users refreshing the confirmation code page during Firefox Sync OAuth flow saw "Bad Request" error
• In-memory OAuth keys (keyFetchToken, unwrapBKey) are lost on page refresh with no recovery path

This pull request

• Adds useOAuthFlowRecovery hook to recover from interrupted OAuth Native flows via Firefox webchannel
• Adds fxaOAuthFlowBegin and fxaOAuthFlowIsActive commands to firefox.ts
• Updates SigninTokenCode and ConfirmSignupCode to attempt recovery when state is missing
• Redirects to /signin with fresh OAuth params on successful recovery

Issue

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

Checklist

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

Other Information

How to test:

1. Open Firefox → Settings → Sync → Sign in
2. Enter credentials, reach confirmation code page
3. Refresh the page (F5)
4. Should redirect to /signin instead of "Bad Request" error

Note: Requires Firefox with fxaccounts:oauth_flow_begin webchannel support

YOu can download it here: https://drive.google.com/file/d/1oKZHHJXqJ5C0LniU-iJwxnLoCQE1FvWt/view?usp=drive_link

[LZoog]

I have latest Nightly, but I've tried 3 times and keep getting this error on confirm signup refresh:

[LZoog]

Looks like we need this added to an FTL file.

[LZoog]

Just a nit but it could be good to have JS Doc style comments for this type, mostly because I'm not sure if I'd know what isRecovering means in this context without digging in a bit more. Something like, "The oauth query params from the browser are no longer valid (oftentimes from a page refresh) - are we currently fetching fresh params via webchannel?" would make it super clear to me.

[LZoog]

Since we later check const responseData = message.data || message.params I guess we're saying one or the other is present - we could do something like...

interface FirefoxMessageBase {
  command: FirefoxCommand;
  messageId: string;
  error?: string;
}

interface FirefoxMessageWithData extends FirefoxMessageBase {
  data: Record<string, any> & {
    error?: {
      message: string;
      stack: string;
    };
  };
  params?: never;
}

interface FirefoxMessageWithParams extends FirefoxMessageBase {
  params: Record<string, any>;
  data?: never;
}

export type FirefoxMessage =
  | FirefoxMessageWithData
  | FirefoxMessageWithParams;

... Feels like a lot of types but could be worth it for clarity? I'll leave it up to you.

[LZoog]

I guess one small improvement here is setting the return type to as unknown as Integration so you don't have to set each one as any further down in each test. Better though would be no casting here at all - it'd require setting integration: Integration in the hook, to something like integration: UseOAuthFlowRecoveryIntegration and then setting that to only what we need, similar to how we do others like SigninIntegration. 🤔

[LZoog]

Makes sense to check this for isOAuthNativeIntegration and not just Sync flow 👍

There might be an opportunity to share more of this in the hook so any time we use it it'd prevent some extra set up but eh maybe this is more clear and we don't need it in too many places.

[LZoog]

I'm having problems getting Firefox running from the download link and this isn't available in Nightly yet so I'm going to r+ based on what I see in the code, and sounds like we might pair for a bit later too.

My only real "blocker" is the FTL file update, but had one or two other suggestions as well.

[mhammond]

Sammy pointed out that desktop really should have used data in the first place, and pointed this line out to show how now either works. So I took the liberty of changing it to data instead of params, meaning this work-around can be removed if you like. cc @LZoog @vbudhram @skhamis