Show live payment confirmation in Liquid receive view

[thibistaken]

When receiving Liquid, the receive screen gives no live feedback that a payment arrived. The user has to leave the screen, go back, and manually refresh before the incoming amount shows up. The Lightning receive view already transitions to a "paid" confirmation state (green screen / checkmark) in real time — Liquid should do the same.

User story

As a user receiving Liquid, when a payment arrives while I'm on the receive screen, I see a confirmation state (green screen / checkmark / amount received) without having to leave and refresh.

Context

Lightning gets real-time updates via the Boltz websocket; Liquid (Electrum) has no websocket. Suggested approach: while the receive view is open, poll the currently-displayed receive address and detect the incoming transaction / balance change, then transition to the confirmed state — the same detection that already works from the main screen on refresh.

Acceptance criteria

• Receive view detects an incoming payment to the displayed Liquid address while open
• On detection, view transitions to a confirmation state consistent with the Lightning receive UX
• Polling stops when the view is closed (no background/battery drain)
• Works for the 0-conf / mempool state and updates on confirmation

Backend API: Not required (client-side polling of existing address/balance data).

[thibistaken]

Test cases

Happy path

• Open Liquid receive view, send a payment to the displayed address → view transitions to confirmation state (green / checkmark / amount) without leaving or manually refreshing.

Confirmation progression

• Payment lands in mempool (0-conf) → view reflects "received / pending" state, then updates when it confirms.

Edge cases

• No payment arrives while view is open → view stays in the waiting state, no false positive.
• Payment sent to a previously-generated (not currently displayed) address → verify expected behaviour (detected vs. not) and that it doesn't wrongly confirm the current invoice.
• Underpayment / overpayment → amount shown matches what actually arrived.
• App backgrounded then foregrounded on the receive view → polling resumes correctly.

Resource / lifecycle

• Close or navigate away from receive view → polling stops (no lingering timers / battery drain).
• Poor or dropped connectivity → no crash; recovers when connection returns.

Regression

• Lightning receive confirmation flow unchanged.
• Bitcoin (on-chain) receive view behaviour unchanged.