Using `signInWithRedirect` with an `authDomain` different than the domain of the app does not complete the sign in (and reports no errors)

### Operating System

Ubuntu 20.04 LTS

### Browser Version

Chrome 119.0.6045.123 / Firefox 119

### Firebase SDK Version

10.7.0

### Firebase SDK Product:

AppCheck, Auth

### Describe your project's tooling

Next.js (React app), using pages router. Deployed on Vercel.

### Describe the problem

I'm migrating Firebase `signInWithPopup` to `signInWithRedirect`.

If I don't implement the best practices listed [here](https://firebase.google.com/docs/auth/web/redirect-best-practices#proxy-requests), the login works fine on Chrome (but not on Firefox and Safari as the documentation states). Implementing the Option # 3 of the documentation (which changes the authDomain of Firebase's configuration to point to our servers, and adds a proxy to rewrite the URLs to Firebase's domain), makes this work on all browsers on my **dev** environment (where I use a real Firebase project, not an emulation).

**The issue happens on the staging environment**, where I have different deployments (that are deployed on each PR, with unique URLs), that all point to the main staging URL as the authDomain (let's call it "www.staging.com" ). As they are all unique URLs I cannot allow them all in Google's OAuth list, which is the reason they all point to "www.staging.com", instead of "www.randomUrl123.com" (as an example of one of the PR deployments).

Unfortunately, in the PR deployments, the sign in does not succeed on "www.randomUrl123.com". It first redirects to "www.staging.com" as expected, then to Google (to perform auth), and then redirects back to "www.randomUrl123.com", but no sign in happens, and `getRedirectResult` returns `null` instead of throwing an error. The browser console is also empty, so I'm not really sure how to debug this.

The reason I'm filing this as a bug is that the console does not report any issues, the browser tab only has requests with statuses 200 or 302, and `getRedirectResult` returns `null` instead of an error. I think we should get some kind of error here to help us debug where this sign in attempt failed.

There is no way for me to allow all the possible URLs like "www.randomUrl123.com" on Google's OAuth, so I must find a way to ensure this works through "www.staging.com"

### Steps and code to reproduce issue

On signIn button:
``` ts
const auth = getAuth();
signInWithRedirect(auth, provider); // The provider I'm testing is Google's OAuth
```

On `_app.tsx`:
``` ts
useEffect(() => {
;(async () => {
const auth = getAuth();
try {
const res = await getRedirectResult(auth)
console.log(res)
} catch (err) {
console.log(err)
}
})()
}, [])
```

On the dev environement, this resolves to the `UserCredentialImpl` object, but on "www.randomUrl123.com" this always return null, instead of an error (even though the sign in did not succeed).

I confirmed the issue is caused by using an `authDomain` different from the domain the app is hosted to, as I changed the `authDomain` on the staging environment to be "www.randomUrl123.com" and the sign in succeeded on "www.randomUrl123.com" . Given what I mentioned above, I would expect to see the following:
- An error that states sign in could not be completed, and why
- Why it did not work, and how can we make it succeed (note that I cannot allow all the possible URLs, so there must be a way to make sign in work when redirecting to a different `authDomain`)

Start by reproducing the flow from the sign-in button and _app.tsx, using signInWithRedirect and getRedirectResult with different app and authDomain hosts. Compare the dev and PR-deployment redirects, including the documented proxy setup and network responses. Done means the failure is surfaced with a useful error or the supported way to complete this cross-domain flow is documented.

Written by the indexing model from the issue text.