fix(autonatv2): secondary addrs inherit reachability from primary

[lidel]

Unsure if this was discussed before. I've seen @MarcoPolo hinting at something like this in @sukunrt's PR #3356, but afaik it was not implemented.

Problem

This PR aims to future-proof AutoNAT v2 so it doesn't lose its usefulness over time.

As the Amino DHT gains more diverse implementations (2025 Q4), different nodes will only support different subsets of protocols. We've already observed false negatives where AutoNAT v2 probes failed not because the port was blocked, but because the probing peer simply didn't support the protocol.

This problem is real and will only get worse. We've seen:

• Nodes disabling QUIC because of memory issues
• Nodes disabling TCP because of consumer router issues
• Custom builds that disable WebSockets and WebTransport, using only raw TCP

All of these nodes can still act as AutoNAT v2 servers, but with a limited set of transports. This acts as artificial chokepoint for deploying new protocols: they become punished by the fact majority of AutoNAT probe servers do not support them.

There is also a chicken-and-egg problem with AutoTLS (p2p-forge): WSS probes fail during initial setup because the TLS certificate is not provisioned yet. Without inheritance, WSS would be marked unreachable and excluded from announcements. Waiting for the next probe cycle means ~5 minutes without WSS on initial start or when the cert needs renewal.

Solution?

As per usual, I'm mostly improvising here, likely lacking historical context, and trying to fix problem with minimal code changes.

Secondary transports (WSS, WebTransport, WebRTC) now inherit ReachabilityPublic from their primary transport (TCP, QUIC) when they share the same network socket.

Based on my limited understanding this change is a prerequisite to reduce the false negatives produced by AutoNAT peers. When the primary confirms the port is reachable over the network, secondary addresses sharing that socket are also reachable to peers that support those protocols. Inheriting Public from a confirmed primary avoids incorrect Private status caused by protocol-level probe failures.

Inheritance is conservative: only Public propagates. Private does not propagate because it could indicate protocol-specific issues rather than port unreachability, so secondaries still get probed independently.

Feels like safer default long-term, but we could also make this opt-in behavior via configuration option, if that is preferable – lmk

Or maybe I missed the point here entirely?

[sukunrt]

This seems fine to me. I was conservative when implementing this and required 1 confirmation for the secondary address before marking it as primary. To inherit this from primary is fine too.

[lidel]

@sukunrt fixed go check, lgtm from my end too.

would be nice to ship it early in January, so we can include it in Kubo 0.40, helping with AutoTLS false-negatives.