fix: add retry logic for channel monitor retrieval during migration

[jvsena42]

Description

This PR fixes a critical bug where channel monitor retrieval failures during migration from the React Native app were silently dropped, potentially causing permanent loss of Lightning channel state.

1. Adds retrieveChannelMonitorWithRetry method with configurable retry attempts and linear backoff
2. Implements parallel retrieval with proper error tracking for each channel
3. Logs individual failures with channel IDs for debugging
4. Validates expected vs retrieved monitor count with warnings

This is the iOS equivalent of the Android fix: synonymdev/bitkit-android#760

Linked Issues/Tasks

Related: synonymdev/bitkit-android#760

Screenshot / Video

N/A - internal migration logic fix

[jvsena42]

E2E migration
https://github.com/synonymdev/bitkit-ios/actions/runs/21593366440

[pwltr]

Is it intentional that we continue with restoring if one or more channel monitors fail to retrieve? Seems to me like we should only restore if everything goes right, and if not show the restore error.

[jvsena42]

Is it intentional that we continue with restoring if one or more channel monitors fail to retrieve? Seems to me like we should only restore if everything goes right, and if not show the restore error.

I thought that if an error happens for some reason that we don't know yet, other than just connection, the user could be stuck outside the wallet

On the case that we got from support, the wallet migrate almost all the channels except one, that was force closed

But I agree, the restore error is also a valid solution, since the user could also try to restore from mnemonics if they are backed up

[pwltr]

It might be okay to continue if the channel_manager restores even if all of the channel_monitors fail if that's what we want to do, at least then the channels will force close and the user will get their funds. But continuing without channel_manager seems problematic, since the user will not see their LN balance without any further information (I believe, haven't tested). The design also has UI for this case, which I think is not implemented:

[pwltr]

utACK, comments above not applicable to this PR.

[jvsena42]

But continuing without channel_manager seems problematic, since the user will not see their LN balance without any further information (I believe, haven't tested)

Indeed, that is what happened. I found it was a force close from the logs

[jvsena42]

Waiting for the migration tests to succeed

https://github.com/synonymdev/bitkit-ios/actions/runs/21628335768