fix(android): share atomic storage creation across access paths

[OskarEichler]

Summary

Reuse getStorage's computeIfAbsent path when constructing RNStorage to prevent redundant native storage creation.

Compatibility / observable behavior

No API change; concurrent callers no longer initialize an unused database instance.

Related to #1331. This is a focused part of a source review; it does not claim the entire repository is bug-free.

Test Plan

• Compiled actual Kotlin registry with a controlled two-thread constructor overlap: simultaneous RN/native access creates two SharedStorage instances before, one after; both paths return the same retained instance.
• Upstream yarn build:js, yarn test:ts (6 tasks), yarn test:lint (6 tasks), yarn test:format and git diff --check pass on the combined review checkout.
• No checked-in test/spec files changed. Reproductions were isolated and used synthetic data, not production/user storage.
• The combined 3.1.1 backport passes consumer immutable install/lint, both products' Android Debug and iOS Simulator Debug builds, four production Metro bundles, 13 web targets and four browser-extension targets. Published native framework binaries are unchanged. React Doctor: 100/100.
• Shared-storage testAndroidHostTest, macosArm64Test and iosSimulatorArm64Test pass with Java 21. The first Android run used Java 17 and failed Robolectric's SDK 36/JDK check; rerunning with the project's documented JDK fixed the environment failure without a source workaround.
• Windows/WinRT runtime, signed releases and physical-device behavior have not been verified locally.

[changeset-bot]

🦋 Changeset detected

Latest commit: ee05799

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@react-native-async-storage/async-storage	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[krizzu]

if this PR is only to "prevent redundant native storage creation.", getOrPut already does just that.

[OskarEichler]

The specific race was across getStorage and getRNStorage: Kotlin’s ConcurrentMap.getOrPut may evaluate its default more than once under contention, while computeIfAbsent performs the creation atomically. A concurrent call through each access path can therefore construct two SharedStorage instances even though only one is retained. That said, I understand the decision to leave this path unchanged, so I’ll leave the PR closed.

[krizzu]

yes, that'd make sense for RN if there would be concurrency concerns and need for atomicity here