fix: prevent stale disconnect from marking reconnected broker offline

[ptone]

Summary

• Root cause: When a broker's control channel disconnects and reconnects rapidly (within the same second), the old connection's deferred removeConnection goroutine races with the new connection. It removes the new connection from the map and fires onDisconnect, leaving onlineProviders=0 despite a live WebSocket session.
• Fix: removeConnection now takes a *BrokerConnection pointer and only removes the map entry / fires the disconnect callback when the passed connection is still the active one for that brokerID. Superseded connections are silently skipped.
• Adds two new tests reproducing the exact race scenario described in the issue.

Fixes issue 131

Test plan

• TestControlChannelManager_ReconnectDoesNotTriggerDisconnect — verifies a stale removeConnection from the old connection does NOT fire onDisconnect or remove the new connection
• TestControlChannelManager_StaleRemoveAfterReconnect_ThenRealDisconnect — verifies the full lifecycle: stale remove is skipped, then a real disconnect of the current connection fires the callback correctly
• Existing TestControlChannelManager_OnDisconnectCallback and _NilSafe updated and passing
• Full pkg/hub/... test suite passes

[gemini-code-assist]

Code Review

This pull request addresses a race condition where a rapid disconnect and reconnect of a broker's control channel could leave the broker permanently offline. The fix updates removeConnection to accept and verify the specific *BrokerConnection pointer, ensuring that stale deferred disconnects do not remove newly established connections. Corresponding unit tests have been added to verify this behavior. There are no review comments, and I have no additional feedback to provide.