fix(android): prevent ConcurrentModificationException from deep linking effect

[sentry]

This PR addresses a ConcurrentModificationException occurring on Android, specifically in IntentModule.onHostResume.

Problem:
The original useEffect in useDeepLinking.ts had storeReady as a dependency. When storeReady transitioned from false to true, the effect would re-run, leading to multiple, concurrent calls to Linking.getInitialURL(). On Android, this caused React Native's IntentModule to attempt to modify its internal ArrayList of URL/intent listeners while iterating over it, resulting in a ConcurrentModificationException.

Solution:

1. Split useEffect: The single useEffect has been split into two distinct effects.
2. One-time initialization: A new useEffect with an empty dependency array ([]) now handles the initial Linking.getInitialURL() call and registers the Linking.addEventListener. The initial URL is stored in a useRef to be processed later.
3. Store-ready processing: The existing useEffect now depends only on storeReady. It processes the initial URL (read from the useRef) and handles Shortcuts.getInitialShortcut() and ShortcutsEmitter.addListener only when storeReady is true.

This change ensures that Linking.getInitialURL() is called only once during the component's lifecycle, eliminating the race condition and preventing the ConcurrentModificationException.

Fixes BETTER-RAIL-3S

_{This PR was automatically generated by Sentry. You can adjust this setting at any time.}