fix(peermanager): prefer connected peers in selection

[igor-sirotin]

Problem

Filter/lightpush peer selection (Automatic → SelectRandom, and the
service-slot pubsub-topic path in selectServicePeer) picks uniformly at
random among all peers that support the protocol + pubsub topic, with no
regard for connectedness.

A light node that has learned many peers via discv5 / peer-exchange — some of
them stale or unreachable (e.g. torn-down nodes whose ENRs a bootstrap node is
still advertising) — therefore keeps selecting dead peers for its filter
subscriptions. It churns on failed dials (all dials failed) and the
subscription for a content topic can stay down long enough to miss messages,
even while an already-connected, reachable service node is available.

This is the proximate cause of the flaky status-go light-client functional
tests (status-im/status-go#7513): in CI a failing light node was observed
re-dialing ~18 dead peer-exchange peers 30–70× each over 70s while a perfectly
good connected fleet node sat unused.

Change

Add preferConnectedPeers: bias selection toward peers we are currently
connected to, falling back to the full candidate set when none are
connected (so behavior is unchanged when there is no connected candidate).
Applied in both SelectRandom and the selectServicePeer pubsub-topic path.

Notes

• Backward-compatible: existing peermanager selection tests pass unchanged
  (they don't connect the candidate peers, so the fallback returns the full
  set as before).
• A connected-preference unit test that actually dials a peer is awkward here
  because libp2p identify overwrites the manually-added supported protocols
  after connection (the existing SelectPeerWithLowestRTT test is ordered last
  for the same reason); happy to add one if you have a preferred harness.
• Complements the nwaku-side fix fix(discovery): prune stale discv5 peers from peer store so PX stops serving dead ENRs (#3933) logos-delivery#3939 (stop the
  bootstrap node from serving stale ENRs); this PR makes the client resilient
  regardless of what it is served.

🤖 Generated with Claude Code

[status-im-auto]

Jenkins Builds

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✖️	bca1267	1	2026-06-09 15:30:47	~9 min	unknown	📄log

[Ivansete-status]

LGTM! Great idea

[Ivansete-status]

The func name is pretty self-explanatory

Suggested change

	// Prefer peers we are already connected to, so we don't churn on dialing
	// stale/unreachable peers learned via discovery or peer-exchange.