fix: dynamic trusted peer IPs from Blocktank API

[ben-kaufman]

Description

This PR:

1. Fetches trusted peer IPs dynamically from the Blocktank /info endpoint at startup, instead of relying solely on hardcoded addresses
2. Adds post-connection verification with fallback to preconfigured env peers if zero API-sourced peers connected
3. Updates the hardcoded LND4 IP from 34.65.186.40 to 34.65.153.174
4. Points ldk-node dependency at the fix/peer-address-upsert branch which persists updated peer addresses on connect

Previously, iOS used only hardcoded peer addresses. When LND4's IP changed, the app kept retrying the stale address indefinitely. Android already fetched peers from the Blocktank API — this brings iOS to parity.

The ldk-node fix (synonymdev/ldk-node#53) ensures that even without an app update, Node::connect with the new IP will persist the updated address and the reconnection loop will use it going forward.

Linked Issues/Tasks

• upstream ldk-node issue #700
• synonymdev/ldk-node#53

Screenshot / Video

N/A — no UI changes, peer connection logic only.

QA Notes

1. Fresh install

• Install fresh, create wallet, verify peers connect using IPs from the Blocktank API (check logs for "Using N trusted peers from Blocktank API")

2. Existing install (stale LND4 IP cached)

• Update from previous version where LND4 had the old IP
• On startup, verify logs show the updated IP being used and LND4 connects successfully

3. API unreachable

• Simulate Blocktank API failure (e.g., airplane mode during startup)
• Verify fallback to hardcoded env peers (check logs for "No remote peers available, falling back to preconfigured env peers")

4. API returns unreachable peers

• If all API peers fail to connect, verify fallback logic triggers for any non-overlapping env peers (check logs for "No trusted peers connected, trying N preconfigured env peer(s)")

Made with Cursor

[ovitrif]

utAck

proceeding to test 🧪

[ovitrif]

tAck

Tests

Note: Tests 3 and 4 use the Peer Simulation picker added in #458 (stacked on this PR) to simulate edge cases without modifying code or network conditions.

1. 🟢 Fresh Wallet: new LND4 peer connected instead of old one, trusted peers fetched from api/info

INFOℹ️: Fetched 3 trusted peers from Blocktank API [WalletViewModel.swift: fetchTrustedPeersFromBlocktank() line: 277]
INFOℹ️: Using 3 trusted peers from Blocktank API [LightningService.swift: connectToTrustedPeers(remotePeers:) line: 317]

2. 🟢 Existing install (stale LND4 IP cached)

• Built branch release-2.0.4 & installed app using old version (using commit of last tag)
• Loaded old wallet, confirmed it uses old LND4 as one of the 3 trusted peers
• Built this branch & installed app of this branch
• Confirmed IP of LND4 is updated (see imgs)

Before	After

3. 🟢 API unreachable → fallback to env peers

• Used Peer Simulation picker in LDK Debug screen (set to API Failure)
• With wallet loaded, selected it, then restarted Lightning node from LDK Debug screen
• Confirmed fallback to hardcoded env peers:

WARN⚠️ : ⚠️  [DEBUG] Simulating Blocktank API failure [WalletViewModel.swift: fetchTrustedPeersFromBlocktank() line: 247]
WARN⚠️ : No remote peers available, falling back to preconfigured env peers [LightningService.swift: connectToTrustedPeers(remotePeers:) line: 321]

4. 🟢 API peers unreachable → verify + env fallback

• Verified verifyTrustedPeersOrFallback logic handles case where API peers connect but none are reachable
• Since env peers and API peers share the same node IDs (LND4), verification correctly logs:

WARN⚠️ : No trusted peers connected. All preconfigured env peers overlap with API peers (not retrying with stale addresses). [LightningService.swift: verifyTrustedPeersOrFallback() line: 350]

• This is correct behavior: avoids retrying with stale hardcoded IPs when the same nodes were already attempted via fresh API addresses