…lueWallet#8093)

Follow-up to Copilot review on BlueWallet#8597. After making `Transaction.confirmations`
optional, the BIP47 add-contact flow in `PaymentCodesList._addContact` only
guarded one of the two branches that read `confirmations`. The other branch
still compared `notificationTx.confirmations === 0`, which is `false` when
the field is `undefined` (real mempool tx). Both branches would then skip
and the code would fall through to creating a *duplicate* notification
transaction even though a perfectly valid one already exists in the mempool.

Normalize once via `const notificationTxConfirmations = notificationTx?.confirmations ?? 0;`
and use the local in both comparisons so an unknown / mempool count is
consistently treated as 0 (= unconfirmed).

DefaultPreference.setName was the one call in _initConnection outside
the try/catch that guards the other preference writes. If the app
group is unavailable it rejects, the connection attempt dies before
reaching the Electrum client, and fire-and-forget callers (settings
screen, internal retry loop) surface it as an unhandled rejection.

Scoped equivalent of BlueWallet#7594 for this fork's older
BlueElectrum.js. Their BlueWallet#8597 (optional confirmations on mempool txs)
needs no port: this code base already normalizes confirmations at
ingestion and null-checks the comparisons.

… guards, Electrum connect resilience (#200)

* fix(ios): patch react-native-tcp-socket onConnect nil-address crash

GCDAsyncSocket's localHost/connectedHost return nil once a socket has
disconnected. If the connection drops between the TLS handshake
completing and the connect event being built, onConnect: inserts nil
into the event dictionary, throwing an uncaught
NSInvalidArgumentException on the module queue and aborting the app.
This is the top field crash on 2.0.x (Electrum connections during
import/discovery are the main trigger).

Ports BlueWallet's patch-package fix 1:1 (BlueWallet#8576)
against the same pinned 6.4.1; upstream library bug is still open
(Rapsssito/react-native-tcp-socket#197). The guard emits an error
event instead of skipping silently so the JS side doesn't hang.

* fix: crash focusing amount input via stale ref access

The component mixed two ref styles: a createRef object and a callback
ref that replaced it with the raw node on mount. Depending on timing,
one of the two focus paths always dereferenced the wrong shape
(.current on a raw node, or .focus() on an unmounted ref) and threw,
which is a fatal crash in release builds.

Uses the createRef object consistently and focuses via .current?.
Same defect class as BlueWallet#7572; equivalent fix
adapted to this component's older class-based shape.

* fix: guard multisig xpub lookup and address-list derivation

An undefined or unregistered cosigner entry reached
isXprvString(undefined) inside address derivation, throwing a cryptic
TypeError; on the addresses screen a single failing derivation killed
the whole list.

Throw a clear error from _getXpubFromCosigner and derive each address
in the list behind try/catch so one bad entry degrades gracefully.
Equivalent of BlueWallet#7893 adapted to this fork's
value-based cosigner lookup.

* fix: keep Electrum connect alive when app-group preferences fail

DefaultPreference.setName was the one call in _initConnection outside
the try/catch that guards the other preference writes. If the app
group is unavailable it rejects, the connection attempt dies before
reaching the Electrum client, and fire-and-forget callers (settings
screen, internal retry loop) surface it as an unhandled rejection.

Scoped equivalent of BlueWallet#7594 for this fork's older
BlueElectrum.js. Their BlueWallet#8597 (optional confirmations on mempool txs)
needs no port: this code base already normalizes confirmations at
ingestion and null-checks the comparisons.

* fix: reset pending-payment state when switching wallets on receive screen

The receive screen's pending-payment watcher (showPendingBalance /
showConfirmedBalance / initial balance baselines / eta / poll cadence)
was left untouched by the wallet selector, and the view flags render
stacked rather than exclusively. After a payment arrived and the user
switched to another onchain wallet, the new wallet's address rendered
together with the previous wallet's pending widget; the stale baselines
could also make the poller misreport a received amount for the new
wallet, and the stale bip21 string kept the poller checking the old
address during the switch.

Reset the whole watcher state machine in onWalletChange. The wallet
selector on this screen is fork-specific, so there is no upstream
BlueWallet fix to port.

* fix: release camera when leaving the multisig cosigner-scan screen

The cosigner scanner on add-multisig step 2 rendered its Camera
unconditionally. After Create navigates to the wallet, the screen stays
mounted in the stack underneath, so the camera session stayed open
(camera-in-use indicator) and onReadCode kept firing — scanning any QR
from an unrelated screen popped the not-a-cosigner validation alert.

Gate the Camera on useIsFocused, the same pattern every other scanner
screen in the repo already uses (ScanQRCode, ScanCodeSend,
importMultisignature).

* fix: remove LayoutAnimation, deprecated and unreliable on the new architecture

LayoutAnimation.configureNext arms a GLOBAL animation for whatever
layout commit happens next. Several call sites here fire at
network-dependent moments (send-screen fee fetch, exchange-rate
refresh), so the armed animation can collide with unrelated commits —
on Fabric this intermittently leaves views with a layout frame but no
drawing. Prime suspect for the field report of the send screen's
amount/recipient inputs rendering as blank space while the rest of the
screen stays intact (width, scroll-offset and empty-data explanations
were each ruled out by on-device injection tests).

Ports BlueWallet#8541, which removed every LayoutAnimation
call after their RN 83 upgrade for the same reason. Only cosmetic
easing on unit switches and fee/discovery loads is lost.

* fix: clear amount and label inputs when switching wallets on receive screen

The watcher-state reset left the custom amount and label fields
populated, so after a wallet switch the form showed the previous
wallet's values while the QR encoded the plain new address. Clear the
label and reset the amount via the hook's existing resetInput, as the
boltcard and cashier screens already do.