fix: topology manager uses actual connection count instead of filtered count

[sanity]

Summary

Fixes #1962 - The topology manager's adjust_topology() function was using filtered connection count instead of actual connection count when making topology decisions.

Root Cause

The adjust_topology() function received neighbor_locations which had been filtered to exclude connections younger than 5 seconds. During network startup, all connections are < 5 seconds old, so neighbor_locations.len() = 0 even when the node has connections. This caused the manager to constantly try adding more connections.

This bug was actually helping some tests pass by bypassing the min_connections check during startup, preventing connection churn in small test networks that would otherwise try to reach 25 connections.

Changes

1. Added current_connections parameter to adjust_topology() to pass the actual connection count
2. Updated min_connections check to use actual count instead of filtered count
3. Added early exit for small networks (< 5 connections) to prevent resource-based topology adjustments from destabilizing them during startup
4. Updated all test calls to pass the connection count parameter
5. Updated logging to show both actual and filtered connection counts for better debugging

Testing

• ✅ All 8 topology module tests pass
• ✅ Test coverage includes min_connections behavior, resource-based adjustments, and the no-duplicate-connections scenario
• Test: test_remove_connections
• Test: test_add_connections
• Test: test_no_adjustment
• Test: test_no_peers
• Test: test_topology
• Test: test_resource_manager_report
• Test: test_update_limits
• Test: test_no_duplicate_connections_with_few_peers

Impact

This fix ensures the topology manager makes decisions based on actual network state rather than filtered state. The early exit for small networks (< 5 connections) prevents resource-based adjustments from causing churn during network startup or in small test networks, improving stability.

Related

• Reverted fix attempt in PR feat: proximity-based update forwarding (clean implementation) #1937 (commit 02e63ef)
• Related to PUT operation issues in PUT response delivery fails in 2-node networks with proximity cache broadcasts #1960

[AI-assisted debugging and comment]

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com