Kad — Restore network-change grace handling around routing persistence and probing

Summary

eMuleAI had a useful network-change grace period that the current target dropped. When the local network interface changes (VPN connect/disconnect, Wi-Fi roam, DHCP renewal, laptop sleep/wake), the current code may:

• Immediately start probing stale contacts with the old endpoint.
• Write a poor nodes.dat snapshot immediately after the rebind.
• Confuse "routing table is stale" with "routing table is empty".

This is particularly bad on: - Mobile/laptop users (frequent interface churn) - VPN users (endpoint changes on every connect) - Dual-home machines (Wi-Fi ↔ Ethernet failover)

Proposed Grace Handling

1. Detect network-change events — hook into Windows NotifyAddrChange or equivalent to detect local IP changes.
2. Grace period — after detecting a change, delay:
3. Routing table persistence writes (avoid overwriting good nodes.dat).
4. Active probing of existing contacts (avoid flooding stale contacts).
5. Bootstrap retriggers (give the new interface time to stabilise).
6. Distinguish states in diagnostics:
7. "Network unstable" (recent interface change, in grace period)
8. "Routing table empty" (normal cold start)
9. "Routing table stale" (contacts present but not yet reverified)

Protocol Compatibility

This is local resilience policy — no Kad packet changes.

Prior Art

eMuleAI implemented a version of this. The target should design a version compatible with the current one-buddy architecture rather than porting directly.

Files

• srchybrid/kademlia/kademlia/Kademlia.h / .cpp — bootstrap and routing state
• srchybrid/kademlia/routing/RoutingZone.h / .cpp — persistence gate
• srchybrid/kademlia/utils/NodesDatSupport.h / .cpp — save path gate
• New: network-change detection helper (Windows NotifyAddrChange wrapper)