[Feat]: Send: add pending payment UI

[pwltr]

Duplicated from iOS: synonymdev/bitkit-ios#448

Problem or use case

If a payment is being held by the payee, the UI just stays in the loading state forever.

Proposed solution

After 10 seconds, show a pending payment UI that the user can close

[pwltr]

Implemented on iOS here: synonymdev/bitkit-ios#465

Lightning Send Timeout & Pending Screen — Spec

1. Timeout behavior

• Wrap the Lightning send with a 10-second timeout.
• If the send does not finish in 10 seconds: call the timeout callback, then throw/return a timeout error.
• If the send finishes before timeout: return normally with the payment hash/ID.

2. Pending route

• Add a “pending” screen in the send flow.
• When the timeout callback runs, navigate to the pending screen and pass the payment hash (or ID).
• Pending screen shows: hourglass/loading, View Details (opens activity by payment ID), Close.

3. Pending tracking

• Keep an in-memory set of payment hashes (or IDs) that are currently shown on the pending screen.
• Add a hash when navigating to pending.
• Remove a hash when: user leaves the pending screen (Close, View Details, swipe), or when the payment result is handled.
• Use the equivalent of onDisappear / view-lifecycle cleanup to remove the hash when the pending screen is dismissed in any way.

4. Event handling

• Listen for paymentSuccessful and paymentFailed from LDK (or equivalent).
• Resolve the payment ID with paymentId ?? paymentHash (or platform equivalent).
• If that ID is in the pending set:
  • Remove it from the set.
  • For success: show a success toast and emit a “resolution” event with (paymentHash, success: true).
  • For failure: emit a resolution event with (paymentHash, success: false), then show a failure toast.
• If the ID is not in the pending set, do not emit a resolution (no special handling for non-pending sends).

5. Pending screen resolution

• Subscribe to the resolution event.
• When a resolution for the current payment hash arrives, clear the resolution and navigate to Success or Failure based on the success flag.
• Ensure the pending screen can append routes to the send flow (e.g. via a navigation binding/path).

6. Send flows

• Apply the same timeout + pending behavior in: standard confirm, Quickpay, LNURL Pay.

7. Payment hash

• Derive the payment hash from the bolt11 before starting the send.
• Fail early if the bolt11 cannot be parsed; do not send in that case.
• Use the parsed hash in the timeout callback and for pending tracking. Never rely on optional/fallback hash there.

8. Error handling

• If timeout occurs and the hash was available: do not show an error; the pending screen is shown.
• If timeout occurs and no hash was available: show an error and navigate to Failure.