feat: skip Choose Payment Method view if not other option

[ajaysehwal]

Description

Please enter a description and screenshots, if appropriate, of the work covered in this PR

This PR removes duplicate Lightning / LNURL / lightning-address / ecash payment routing from the swipeable row components, moves list building and navigation into utils/ChoosePaymentMethodUtils.ts, and replaces the Choose Payment Method screen when exactly one payment method row is selectable (so users are not shown a pointless picker)

Test Plan

• Open Choose Payment Method for a payment where only one method is available with balance (e.g single-path invoice or only on-chain). Confirm the screen skips to the Choose payment method flow.
• Open the same screen for a payment with two+ available methods with balance (e.g. Lightning + e-cash). Confirm the list appears and each option still opens the expected screen.
• On the list, swipe Send on Lightning and (if shown) ecash / on-chain rows; confirm navigation matches inten
• start while wallet is syncing—if skip does not run until sync ends, that matches current syncStore.isSyncing guard.
• Back after auto-skip: stack should return to a sensible previous screen.

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Configuration change
• Locales update
• Quality assurance
• Other

Checklist

• I’ve run yarn run tsc and made sure my code compiles correctly
• I’ve run yarn run lint and made sure my code didn’t contain any problematic patterns
• I’ve run yarn run prettier and made sure my code is formatted correctly
• I’ve run yarn run test and made sure all of the tests pass

Testing

If you modified or added a utility file, did you add new unit tests?

• No, I’m a fool
• Yes
• N/A

I have tested this PR on the following platforms (please specify OS version and phone model/VM):

• Android
• iOS

I have tested this PR with the following types of nodes (please specify node version and API version where appropriate):

On-device

• LDK Node
• Embedded LND

Remote

• LND (REST)
• LND (Lightning Node Connect)
• Core Lightning (CLNRest)
• Nostr Wallet Connect
• LndHub

Locales

• I’ve added new locale text that requires translations
• I’m aware that new translations should be made on the ZEUS Transfix page and not directly to this repo

Third Party Dependencies and Packages

• Contributors will need to run yarn after this PR is merged in
• 3rd party dependencies have been modified:
  • verify that package.json and yarn.lock have been properly updated
  • verify that dependencies are installed for both iOS and Android platforms

Other:

• Changes were made that require an update to the README
• Changes were made that require an update to onboarding

[gemini-code-assist]

Code Review

This pull request centralizes payment method row construction and navigation logic into a new utility file, ChoosePaymentMethodUtils.ts, and refactors EcashSwipeableRow, LightningSwipeableRow, OnchainSwipeableRow, and PaymentMethodList to utilize these shared helpers. It also implements an auto-skip feature in ChoosePaymentMethod.tsx that automatically navigates when only one selectable payment method is available. Reviewer feedback suggests further refactoring to unify error handling for asynchronous navigation, enhancing type safety by replacing any with specific interfaces, and adding logging or alerts to prevent silent failures in navigation logic.

[gemini-code-assist]

Using any for the params variable reduces type safety. Since getlnurlParams returns a union of specific LNURL parameter types from the js-lnurl library, it's better to use a proper type or union to ensure that properties like tag and status are accessed safely.

[gemini-code-assist]

The data parameter in onLnurlp is typed as { callback?: string }, but it's expected to be a full LNURLPayParams object. Using a more complete type would improve clarity and prevent potential runtime issues if other properties are accessed in the future.

[gemini-code-assist]

This silent return might make the UI feel unresponsive if lightningAddress is missing from the context when a 'Lightning address' row is selected. While the current logic for building rows should prevent this, adding an error log or an alert would make the code more robust and easier to debug.