[firestore][android] fix instance cache key for Firestore initialization

[michaelpomogajko]

Summary

• fix the Android Firestore instance cache write to use firestoreKey
• avoid cache misses that can lead to repeated setFirestoreSettings(...) calls

Details

getFirestoreForApp() reads from instanceCache using appName + ":" + databaseId, but was writing back using only appName.

That makes the cache internally inconsistent:

• lookup key: firestoreKey
• write key: appName

This change makes the cache write use the same key as the lookup.

Fixes #8981

---

Note

Low Risk
Small, localized change to cache key selection; main risk is altered instance reuse behavior for apps using multiple Firestore database IDs.

Overview
Fixes an Android Firestore caching bug where getFirestoreForApp() stored instances in instanceCache under appName instead of the composite firestoreKey (appName:databaseId).

This aligns cache writes with cache reads, preventing cache misses and avoiding repeated setFirestoreSettings(...) application for the same app/database pair.

^{Reviewed by Cursor Bugbot for commit 4f5ead2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

@michaelpomogajko is attempting to deploy a commit to the Invertase Team on Vercel.

A member of the Team first needs to authorize it.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[gemini-code-assist]

Code Review

This pull request corrects a cache key mismatch in UniversalFirebaseFirestoreCommon.java by using firestoreKey instead of appName for storage. While this fixes the immediate logic error, the reviewer pointed out that the current cache implementation using WeakHashMap is problematic because the locally generated string keys are subject to immediate garbage collection, making the cache ineffective. Additionally, the reviewer highlighted concerns regarding thread safety and potential null pointer exceptions, suggesting a move to ConcurrentHashMap for a more robust implementation.

[gemini-code-assist]

While this change correctly fixes the key mismatch between lookup and storage, the underlying cache implementation remains problematic: (1) Key Reachability: WeakHashMap removes entries when the key object is no longer strongly reachable. Since firestoreKey is a local string created via concatenation, it will be garbage collected quickly, making the cache ineffective and leading to the repeated setFirestoreSettings calls this PR aims to avoid. (2) Thread Safety: WeakHashMap is not thread-safe. Concurrent access to this static map from multiple threads can cause race conditions or internal corruption. (3) WeakReference Handling: The retrieval logic at line 43 (visible in context) returns cachedInstance.get() without checking for null. If the WeakReference is cleared, the method returns null, which may cause a NullPointerException in the caller. Consider replacing instanceCache with a ConcurrentHashMap to ensure persistence, thread safety, and reliability.