Topology manager requests duplicate connections to same peer instead of diversifying

[sanity]

Problem

The topology manager's adjust_topology() function requests duplicate connections to the same peer instead of diversifying across the ring. This prevents mesh topology formation and blocks peers from discovering each other.

Evidence

When running test_three_node_network_connectivity, the topology adjustment logs show:

INFO freenet::ring: Topology adjustment result, 
  adjustment: AddConnections([
    Location(0.9992056995279488), 
    Location(0.9992056995279488), 
    Location(0.9992056995279488),
    ... (repeated 25 times)
  ]), 
  current_connections: 1, 
  is_gateway: true

All three nodes exhibit this behavior:

• Gateway requests 25 connections to Location(0.9992056995279488) (Peer1's location)
• Peer1 requests 25 connections to Location(0.3107304382906112) (Gateway's location)
• Peer2 requests 25 connections to Location(0.14832842390790457) (Gateway's location)

Each node is trying to create 25 duplicate connections to the single peer it's already connected to.

Expected Behavior

The topology manager should return a diverse set of locations spread across the ring to achieve optimal topology. For example, with min_connections=25 and only 3 nodes in the network, it should request connections to both of the other peers, not just one peer repeated 25 times.

Impact

• Blocks mesh formation: Peers never establish peer-to-peer connections
• Network remains in star topology: All traffic must route through gateway
• Poor resilience: Single point of failure
• Test failures: test_three_node_network_connectivity fails after 80+ seconds (40+ maintenance cycles)

Reproduction

cargo test --test connectivity test_three_node_network_connectivity 2>&1 | \
  grep -i "topology adjustment" | head -5

Investigation Needed

1. Check TopologyManager::adjust_topology() logic in crates/core/src/topology/
2. Verify how it selects target locations for new connections
3. Ensure it avoids duplicates and spreads connections across the ring
4. Consider whether it should account for existing connections when suggesting new ones

Related

• Discovered during work on PR fix: enable gateway bootstrap when starting with zero connections #1871 (gateway bootstrap fix)
• Blocks: test_three_node_network_connectivity
• The bootstrap fix itself is working correctly; this is a separate pre-existing issue

[AI-assisted debugging and analysis]

[sanity]

Note on Test Coverage

PR #1871 originally included test_three_node_network_connectivity which validates mesh topology formation in a 3-node network. This test revealed the topology manager bug and is currently blocked by it.

The test will be re-added once this issue is fixed. For now, PR #1871 focuses solely on the bootstrap fix (immediate connection registration), which is working correctly.

Test expectations (once unblocked):

• Gateway: 2 connections
• Peer1: 2 connections (to gateway + peer2)
• Peer2: 2 connections (to gateway + peer1)

[AI-assisted debugging and comment]