feat(retrieval): connect to known peers on-demand when peers are exhausted

[gacevicljubisa]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

When a node has few connected peers, retrieval fails fast because forwarding peers exhaust their sparse connected topology. This PR adds a fallback: when all connected peers are exhausted, the retrieval service calls ConnectClosest to find the closest known-but-disconnected peer to the chunk address, connects on demand, and retries retrieval through it. ConnectClosest tries up to 3 closest candidates (sorted once by proximity) before giving up.

Key changes:

• New OnDemandConnecter interface in topology with ConnectClosest(ctx, addr, skipPeers...)
• (*Kad).ConnectClosest implementation: filters disconnected/non-blocklisted/non-backoff peers from knownPeers, sorts by XOR proximity, attempts connection with parent-context-bounded timeout
• retrieval.Service accepts the connecter as an optional dependency (nil-safe), wired with kad in node.go
• 4 unit tests covering: success path, exhausted attempts, no-op when peers are available, nil-safe behavior

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

[gacevicljubisa]

This was a tryout for improving retrieval fallback approach. After discussion with the team, we've decided to close it for now. We can revisit this idea in the future if needed.