feat(auth): cache password policy per-app in validatePassword

[gyula-s]

Cache the fetched password policy per Firebase app to avoid
redundant API calls to the identity toolkit endpoint.

Description

Every time you call validatePassword(), the library was making an API call to Firebase's Identity Toolkit
to fetch the password policy. When a user types their password character by character (e.g.,
"P-a-s-s-w-o-r-d-1-2-3-$"), that's 12 API calls just for one password entry. If users backspace and
retype, it adds up fast.

Firebase has rate limits on this endpoint, so you hit:
QUOTA_EXCEEDED: Exceeded quota for getting password policy

Why Debounce Didn't Help

Debouncing reduces the frequency of calls, but the real issue is that the password policy never changes
during a user session. It's static configuration set in Firebase Console. Even one call per password field
interaction is wasteful when you could just fetch it once.

The Fix

Cache the password policy after the first fetch:

• First call: Fetches from Firebase API and stores it in memory
• All subsequent calls: Uses the cached policy (zero API calls)

The policy only changes when an admin updates it in Firebase Console, which is rare. So caching it for the
lifetime of the app session is safe and eliminates the quota issue entirely.

Per-App Cache

If your app uses multiple Firebase projects, each app gets its own cached policy (keyed by auth.app.name),
since different projects could have different password requirements.

Related issues

#8780

Release Summary

Fixed validatePassword() causing QUOTA_EXCEEDED errors by caching the password policy
per-app. The policy is now fetched once and reused for subsequent validations.

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
  • Other (macOS, web)
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e (no e2e behaviour changed)
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

TBC - I've implemented this in my code by editing the library directly in node-modules, and it worked.
I still have to set up tests to run properly. (I'm hoping that there are some automated runners that would do that for me ;)

---

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[vercel]

@gyula-s is attempting to deploy a commit to the Invertase Team on Vercel.

A member of the Team first needs to authorize it.

[CLAassistant]

All committers have signed the CLA.

[mikehardy]

🤔 Hmmm - I really appreciate the effort here, the tests are great as well. I'm just not sure we can make caching decisions like this for library consumers. I believe this would fit well at the app level as a React useState var set via useEffect in the component where passwords were set. I am just not sure there is any caching policy we can pick that will be correct in 100% of the consuming app use cases