feat(mobile): add transaction pending state before confirmation (#253)

[cLamberti]

Closes #253

⚠️ Draft — waiting on maintainer input. This PR bundles the #253 feature with 3 unrelated RN/Hermes compatibility fixes I had to make to actually test it on-device (see "Compatibility fixes" below). I flagged this in a comment on #253 asking whether you'd prefer them split into a separate PR — marking this draft until I hear back. Happy to rebase them out if you'd rather keep this PR scoped to the feature only.

Summary

Adds a distinct pending state for submitted transactions instead of implying success the moment submitTransaction() resolves.

• Added a 'confirming' phase to HandoffPhase (between submitting and completed) so the UI shows "Confirming…" with a Pending badge before the flow completes.
• Added optimistic pending entries to walletStore (keyed by transaction hash, not a single slot, so concurrent sends don't clobber each other), reconciled against the next Horizon refresh.
• Extracted a shared StatusBadge component (previously a private Badge in settings.tsx), reused in the review screen, transaction history rows, and settings.
• payment-success.tsx now says "Payment Confirmed" instead of the earlier "Payment Sent / submitted successfully" claim.
• Post-submission failures show neutral copy ("Could not confirm submission — check your transaction history") instead of asserting failure, since a client-side error doesn't prove Horizon rejected the transaction.
• No real Horizon polling — submitTransaction() is synchronous, so there's no genuine post-submit async window to poll. The existing pull-to-refresh on History is the "polling placeholder" per the AC, with a comment marking where a real polling hook would attach.

Acceptance criteria

• Pending state is added
• Confirmed and failed states remain distinct
• Users see clear status copy
• Refresh or polling placeholder is considered
• Missing data is handled safely (unrecognized/absent status falls back to no badge, not a guess)

Compatibility fixes (see note above)

Found while testing the flow end-to-end on an Android emulator — none of these are specific to #253, they block any real transaction submission on the currently-pinned @stellar/stellar-sdk@16.1.0:

1. AbortSignal.timeout missing in Hermes (the SDK's fetch client calls it unguarded)
2. React Native's fetch not serializing a URLSearchParams body (Horizon was receiving an empty envelope)
3. Hermes's .subarray() losing the Buffer prototype (facebook/hermes#1495), so the transaction envelope was reaching Horizon as raw comma-joined bytes instead of base64

All three patched in shim.js. Two other issues I initially hit (metro.config.js's stale stellar-sdk path, tsconfig.json's moduleResolution) were already fixed upstream in 6623bce — this branch is rebased on that.

Test plan

• npx jest — 332/332 passing
• Manually verified on Android emulator: Send → Review (Confirming… + Pending badge) → Payment Confirmed → shows in History
• Maintainer confirms how to scope the compatibility fixes (see note at top)