Keep polling the payment wait endpoint when it times out

[TaprootFreak]

Why

The API is about to cap how long GET /v1/lnurlp/wait/{id} blocks and answer HTTP 408 while the payment is still pending (DFXswiss/api#4502, implemented in DFXswiss/api#4533). Today that request is instead cut off by the CDN after 125 s with a gateway error page.

That difference matters here. fetchJson (src/util/utils.ts) returns the parsed body regardless of status, so today's non-JSON error page makes the promise reject and the poll interval keeps running — the widget recovers by accident. A JSON 408 would instead arrive in the success callback, which calls stopWaitPolling(). And usePolling.init() returned early when called again with the same URL, which is exactly what happens for a wait poll (the URL is derived from the payment and does not change while it is pending). The poll would stop for good and the completed payment would never be picked up.

What

payment-link.context.tsx — a 408 in the wait callback is treated as "nothing decided yet" and the poll continues.

polling.ts — stop() now also releases url.current. It previously kept it, so a restart on the same URL was silently ignored: every stop on a still-pending payment was final. That was the trap the 408 guard had to work around; it is now gone, and a test covers the restart.

payment-link-pos.context.tsx — the POS terminal reaches the same endpoint through call(), which throws on any non-2xx, so its .catch chain already re-issued the wait. Three things were wrong with that retry once 408 becomes a regular occurrence:

• it retried immediately, so an error returning at once would spin;
• it retried a 401 as well, so a terminal whose session had gone re-asked every two seconds for as long as it stayed open;
• the retry timers were untracked, so a pending retry fired for a terminal nobody was using anymore.

The retry now waits, skips the unauthorized case, and every pending timer is cleared on unmount. Because creating a payment starts a wait of its own, the timers are held in a set rather than a single slot — otherwise the older one is lost and fires unattended.

Tests

polling.test.ts covers the restart after stop; payment-link-pos-wait-retry.test.tsx covers both retry rules (ask again after a timeout, stop once the session is gone).

Deployment order

This has to go out before the API-side cap.

[TaprootFreak]

Four review passes were needed to reach zero findings.

Beyond the original one-line guard, the passes surfaced three problems in the paths this change touches:

• usePolling.stop() kept the polled URL, so a restart on the same URL was silently ignored — every stop on a still-pending payment was final
• the POS wait retried immediately and also retried a 401, so a terminal whose session had gone kept calling the endpoint every two seconds
• the retry timers were held in a single slot, so with two waits in flight the older timer was lost and fired after unmount

All are fixed, with tests for the restart and for both retry rules.