feat: connection issues view

[jvsena42]

Related to #873

Description

This PR adds a reusable connection issues overlay view and improves network recovery behavior across multiple flows.

Connection Issues Overlay

• Adds ConnectionIssuesView composable with phone illustration, dashed gradient rings, and a loading spinner
• Integrates the overlay into SendSheet, ReceiveSheet, ForceTransferSheet, SpendingAmountScreen, SpendingConfirmScreen, and SavingsConfirmScreen using AnimatedVisibility
• Auto-dismisses when connectivity is restored, preserving the underlying flow state

canSend Refactor — Replace Cache with Flow-Based State

• Removed cache fallback: canSend() no longer falls back to stale cached balance from DataStore when channels aren't usable — prevents false-positive unified invoices that would fail at payment time
• Pure instant check: canSend() is now a non-suspend function that checks _lightningState.value.channels capacity directly
• waitForUsableChannels() made public: Callers that need to wait for channel readiness (scan flows) call it explicitly before canSend()
• Removed LightningService.canSend(): Logic inlined via totalNextOutboundHtlcLimitSats() extension on reactive state
• Removed dead code: cachedLightningBalance(), CHANNELS_READY_TIMEOUT_MS

SyncNodeView on SendSheet

• Displays SyncNodeView overlay on SendSheet when node is not running or lightning channels aren't usable yet (matching iOS shouldShowSyncOverlay behavior)
• Opens SendSheet early when handling lightning-related deeplinks/scans, so the sync overlay is visible during channel reconnection
• Navigates to Confirm screen before async fee estimation to avoid blocking

Network Recovery Improvements

• SpendingAmountScreen refresh: Re-triggers updateLimits() when connectivity state changes, so the "Available" field updates after coming back online
• IsOnlineTracker fix: Fixed isFirstEmission flag never being set to false, which prevented connectivity toasts from ever appearing
• LightningRepo.awaitPeerConnected(): New method that polls for peer reconnection (up to 30s) before attempting cooperative channel close — prevents "Cannot begin shutdown while peer is disconnected" errors during transfer to savings after internet toggle
• TransferViewModel.closeChannels(): Calls awaitPeerConnected() before attempting cooperative close, reducing unnecessary INTERRUPTED state in the savings progress screen

Preview

Send Sheet Sync View send-sheet-sync-view.webm	Deeplink and QuickPay deeplink-and-quickpay.webm
Receive Sheet receive-sheet.webm	Transfer to Savings transfer-to-savings.webm
Transfer to Spending transfer-to-spending.webm	Scan Sheet (Zero Amount) scan-sheet-zero-amount.webm
Scan Sheet (With Amount) scan-sheet-with-amount.webm	Scan Sheet Sync View scan-sheet-sync-view.webm
Send Sheet (Zero Amount) send-sheet-zero-amount.webm	Send Sheet (With Amount) send-sheet-with-amount.webm

QA Notes

Connection Issues Overlay

1. Open the Send Bitcoin sheet, toggle airplane mode on
   • Connection Issues overlay should fade in over the send flow
   • Title should read "Send Bitcoin"
   • Dashed yellow rings and phone illustration should be visible
   • Spinner should be animating at the bottom
2. Re-enable connectivity
   • Overlay should fade out
   • Send flow state should be preserved (no navigation reset)
3. Repeat for Receive Bitcoin sheet (title: "Receive Bitcoin")
4. Repeat for Force Transfer sheet (title: "Transfer Funds")
5. Repeat for Transfer to Spending screens (amount + confirm)
6. Repeat for Transfer to Savings confirm screen
7. Verify the overlay does not appear when connectivity is stable

canSend / SyncNodeView

8. With node starting, open send sheet → SyncNodeView overlay should show

   • Once node is running and channels usable, overlay fades out

9. Paste BIP21 unified invoice while node is starting

   • SendSheet opens immediately with SyncNodeView visible
   • Once channels become usable, navigates to Confirm screen

10. With node running and channels usable, paste BIP21 → should show both savings and spending options

Network Recovery — Send Flow

11. With on-chain + lightning balance, enable airplane mode → open send sheet → disable airplane mode → paste unified zero-amount invoice

• Both savings AND spending options should appear (not just savings)

Network Recovery — Transfer to Savings

12. Toggle airplane mode off/on → immediately confirm transfer to savings

• Progress screen should wait for peer reconnection and show SUCCESS (not INTERRUPTED)
• Check logs for "Waiting for peer to reconnect" message

Connectivity Toasts

13. Toggle airplane mode on → "Internet Connectivity Issues" warning toast should appear
14. Toggle airplane mode off → "Internet Connection Restored" success toast should appear

[claude]

Code review

[jvsena42]

Note: Small navigation delay when pasting unified invoices

During testing I noticed a ~5.8s delay navigating to SendAmountScreen after pasting a unified (BIP21 + Lightning) invoice. This is a pre-existing issue unrelated to this PR's changes.

Root cause

BlocktankService.info and CoreService.decode both run on ServiceQueue.CORE — a single-threaded queue. When a periodic BlocktankRepo.refreshInfo() coincides with a scan/paste, the slow network call to the Blocktank server (~5.8s) blocks decode from processing the invoice.

Why we can't just move BlocktankService to its own queue

Both services share native Rust state via bitkitcore FFI. The single-threaded CORE queue serializes access to that native database. Moving BlocktankService off it would create race conditions with initDb(), updateBlocktankUrl(), and cross-service calls from ActivityService.

Possible future fixes

This would need to be addressed at the bitkitcore/Rust level (e.g., making the native layer thread-safe so the queue constraint can be relaxed).

[jvsena42]

Everything retested and polished as much as possible ✅