feat(send): improve Lightning send failure recovery

[pwltr]

Summary

• Move Lightning send failures onto the failure screen with localized user-facing messages.
• Add retry support that resets Lightning payment routing caches, waits for local routing data to reload, and returns the user to the correct send confirmation flow.
• Fix retry freshness checks so RGS refresh no longer requires the remote snapshot timestamp to change after the local graph cache is reset.
• Prevent overlapping retry flows from stale failure screens by tracking Lightning retry state outside the recreated view.
• Consolidate PaymentFailureReason user-message mapping into PaymentFailureReason+UserMessage.swift with generic and send-specific contexts.
• Keep send-specific route/retry failure copy for the retry screen while using generic payment failure copy elsewhere.
• Fix stale Lightning node lifecycle state where the view model could think the node was running after the service node was gone.

Closes #483

Simulator.Screen.Recording.-.iPhone.17.-.2026-08-04.at.19.07.07.mov

[greptile-apps]

Greptile Summary

The PR moves Lightning failures into a dedicated retry flow, resets routing caches before retrying, and adds localized failure messages.

• Adds contextual payment-failure messaging and translations.
• Restarts Lightning and waits for refreshed graph and scorer data before returning to confirmation.
• Tracks retry state outside the recreated failure view to prevent overlapping retries.

Confidence Score: 4/5

The PR is not yet safe to merge because a failed Lightning stop can leave the wallet permanently stuck in the stopping lifecycle state.

The recovery path calls start() after a cache-reset error, but when the underlying stop throws, the state remains .stopping and start() returns without restoring the node.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendFailure.swift; Bitkit/ViewModels/WalletViewModel.swift

Important Files Changed

Filename	Overview
Bitkit/Views/Wallets/Send/SendFailure.swift	Implements cache-reset and node-restart recovery, but a stop failure can leave the lifecycle stuck in .stopping.
Bitkit/ViewModels/WalletViewModel.swift	Adds routing-cache reset and freshness polling while retaining a lifecycle state that the retry restart cannot recover.
Bitkit/Views/Wallets/Send/SendSheet.swift	Adds retry-route metadata and restores the corresponding confirmation flow.
Bitkit/Extensions/PaymentFailureReason+UserMessage.swift	Centralizes generic and send-specific localized payment-failure mappings.

_{Reviews (2): Last reviewed commit: "feat(send): improve Lightning send failu..." | Re-trigger Greptile}

[greptile-apps]

Failed stop blocks node restart

When lightningService.stop() throws during the routing-cache reset, the lifecycle state remains .stopping, so this call to wallet.start() returns without restarting the node. The retry then aborts and subsequent starts are also skipped, leaving Lightning operations unavailable until another lifecycle reset occurs.