fix: add network error retry for transfer polling

[jvsena42]

Fixes #608

This PR adds network error resilience to the transfer-to-spending polling mechanism by distinguishing between transient network failures and permanent order errors.

Description

• Uses .fold() instead of .getOrNull() to properly handle Result failures
• Implements a retry mechanism that tolerates up to 5 consecutive network errors before giving up
• Resets the error counter on successful fetches, allowing recovery from intermittent issues
• Preserves immediate exit behavior for permanent failures (order not found, order expired)

Preview

Screen_recording_20260206_132910.mp4

QA Notes

To facilitate the simulation, you can put a breakpoint in the line and then disable internet

 val paidOrder = pollUntil(orderId) { order ->

1. Normal transfer flow (regression)

1. Start a transfer to spending
2. Verify the setup steps progress (0 → 1 → 2 → 3)
3. Confirm the channel opens successfully

2. Network error recovery

1. Start a transfer to spending
2. Enable airplane mode briefly during polling
3. Disable airplane mode before 12.5 seconds (5 retries × 2.5s)
4. Verify polling resumes and completes successfully

3. Persistent network failure

1. Start a transfer to spending
2. Enable airplane mode and keep it enabled
3. After ~12.5 seconds, verify the transfer fails gracefully with appropriate logging

[jvsena42]

from the Logs

2026-02-06 13:29:34.832 14603-14603 APP                     to.bitkit.dev                        W  2026-02-06 16:29:34.831 WARN    [TransferViewModel.kt:287]           Failed to fetch order '579f1d43-647c-4844-9d39-64b0d9336e52' (attempt 3/5) [AppError='errorDetails=Failed to fetch orders: Blocktank error: Failed to fetch orders ["579f1d43-647c-4844-9d39-64b0d9336e52"]: HTTP client error: error sending request for url (https://api.stag0.blocktank.to/blocktank/api/v2/channels?ids%5B%5D=579f1d43-647c-4844-9d39-64b0d9336e52) String("HTTP client error: error sending request for url (https://api.stag0.blocktank.to/blocktank/api/v2/channels?ids%5B%5D=579f1d43-647c-4844-9d39-64b0d9336e52)")'] - TransferViewModel
                                                                                                    to.bitkit.utils.AppError: errorDetails=Failed to fetch orders: Blocktank error: Failed to fetch orders ["579f1d43-647c-4844-9d39-64b0d9336e52"]: HTTP client error: error sending request for url (https://api.stag0.blocktank.to/blocktank/api/v2/channels?ids%5B%5D=579f1d43-647c-4844-9d39-64b0d9336e52) String("HTTP client error: error sending request for url (https://api.stag0.blocktank.to/blocktank/api/v2/channels?ids%5B%5D=579f1d43-647c-4844-9d39-64b0d9336e52)")
                                                                                                    	at to.bitkit.async.ServiceQueue$background$2.invokeSuspend(ServiceQueue.kt:42)

[claude]

According to CLAUDE.md:

NEVER add e = named parameter to Logger calls

The Logger.warn call should pass the throwable without the named parameter syntax.

Suggested change

	e = it,
	Logger.warn(
	"Failed to fetch order '$orderId' (attempt $consecutiveErrors/$MAX_CONSECUTIVE_ERRORS)",
	it,
	context = TAG
	)

[claude]

According to CLAUDE.md:

NEVER use wheneverBlocking in unit test expression body functions wrapped in a = test {} lambda
ALWAYS wrap unit tests setUp methods mocking suspending calls with runBlocking, e.g setUp() = runBlocking {}

Move the mock setup to the setUp method using runBlocking instead of using wheneverBlocking inside the test expression body.

[claude]

According to CLAUDE.md:

NEVER use wheneverBlocking in unit test expression body functions wrapped in a = test {} lambda
ALWAYS wrap unit tests setUp methods mocking suspending calls with runBlocking, e.g setUp() = runBlocking {}

Move the mock setup to the setUp method using runBlocking instead of using wheneverBlocking inside the test expression body.

[claude]

The named parameter e = should not be used in Logger calls.

CLAUDE.md Rule:

NEVER add e = named parameter to Logger calls

Reference: CLAUDE.md:180

Fix:

Suggested change

	e = it,
	it,

[claude]

The wheneverBlocking call should not be used inside = test {} expression body functions.

CLAUDE.md Rule:

NEVER use wheneverBlocking in unit test expression body functions wrapped in a = test {} lambda

ALWAYS wrap unit tests setUp methods mocking suspending calls with runBlocking, e.g setUp() = runBlocking {}

Reference: CLAUDE.md:205-206

Suggested Fix:
Move the wheneverBlocking mock setup to the setUp() method wrapped in runBlocking, as shown in the existing tests in this file (see lines 42-49). Both new test methods (refreshOrders returns failure when server throws and getOrder returns failure when refresh fails) need this change.

Example pattern from existing tests:

@Before
fun setUp() = runBlocking {
    wheneverBlocking { coreService.blocktank.orders(refresh = true) }.thenThrow(RuntimeException("Network error"))
}

[jvsena42]

draft to apply suggestions