Improve wallet fallbacks

[riccardobl]

Description

The purpose of this PR is to ensure that if a payment path exists between a stacker sender wallet and a stacker receiver wallet, it is successfully used. #1494

Key Changes

1. Client-Side:

   • The sending logic now iterates through all attached wallets, attempting to pay the invoice with each one until a successful payment is made.

2. Server-Side:

   • performXXXXAction and retryPaidAction now cycle through all attached wallets to find one that successfully generates a valid invoice. If no wallet succeeds, it falls back to the CC wallet.
   • retryPaidAction tracks which wallet was last attempted. On each retry, it resumes cycling from the next wallet. This handles cases where both sender and receiver have valid wallets but cannot pay each other (e.g., due to liquidity or channel issues). If all attempts fail, it falls back to the CC wallet.

Where a CC wallet fallback is used, I've added a flag to disable it. So we can make it a configurable user setting.

Screenshots

Additional Context

Checklist

Are your changes backwards compatible? Please answer below:

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:

For frontend changes: Tested on mobile? Please answer below:

Did you introduce any new environment variables? If so, call them out explicitly here:

[riccardobl]

i am splitting this into two PRs

• one to prep the server/receiver part: receiver and sender fallback and p2p lnurlp  #1523
• one for the client/sending code: TBD