Add configurable reconnection backoff for persisted peers

[Jolah1]

Following #895 , peers are now retained in the store after force-closes so the background reconnection task can drive channel_reestablish recovery. The reconnection loop currently calls connect_peer_if_necessary on a fixed interval with no backoff, so a persisted-but-unreachable peer is retried at the same cadence indefinitely — log spam and wasted work, and now more visible because retained force-closed peers may never come back.
Proposed approach
Track per-peer failure state and apply exponential backoff, capped at a max. Roughly:
ruststruct PeerReconnectState { consecutive_failures: u32, next_retry_at: Instant, }
with a base/max interval and a next_backoff(failures) that doubles up to the cap. Modeled on the bitcoind RPC backoff approach in #588.
Open questions

Should trusted peers (trusted_peers_0conf) get a shorter max backoff, since reestablish latency matters more for them?
Should the retry state live inside ConnectionManager, or alongside PeerStore?

Happy to put up a PR once there's agreement on the boundary.

[Jolah1]

Opened #951 to implement this. It adds per-peer exponential backoff: each consecutive reconnect failure doubles the wait (starting at the existing 60s PEER_RECONNECTION_INTERVAL) up to a 30-minute cap, and the state resets on a successful connect, an explicit disconnect(), an inbound reconnection, or when the peer is removed after its last channel closes.

One open question for reviewers: the title says "configurable" — the PR currently keeps the base interval and cap as crate constants to match the existing reconnection-interval constant, rather than exposing them on Config. Happy to add Config fields if that's preferred.

It's marked draft because it depends on #895 (peer-removal relocation); I'll rebase and un-draft once that merges.

[tnull]

As mentioned elsewhere, I'm not quite convinced this is a huge issue right now that's worth fixing and/or taking on additional complexity. A better way to solve this would probably also be to simply wait until the peer reconnected once before dropping it, which I now opened over at #983

[Jolah1]

As mentioned elsewhere, I'm not quite convinced this is a huge issue right now that's worth fixing and/or taking on additional complexity. A better way to solve this would probably also be to simply wait until the peer reconnected once before dropping it, which I now opened over at #983

noted.

[Jolah1]

As mentioned elsewhere, I'm not quite convinced this is a huge issue right now that's worth fixing and/or taking on additional complexity. A better way to solve this would probably also be to simply wait until the peer reconnected once before dropping it, which I now opened over at #983

Closing this: #983 (merged) addresses the case that motivated the issue — force-closed peers are no longer retained indefinitely, so there's no longer a class of peers that gets retried forever.
For the remaining case (a temporarily unreachable persisted peer being retried at a fixed 60s cadence), I agree the extra state tracking isn't justified right now. Can revisit if the retry churn shows up as a real problem in practice.