Connection validation is still unreliable, and Ironclad should be a validation stage rather than a scan mode

[MrArrowww]

First of all, thank you for the continued improvements in Aether. The recent releases have introduced many useful features and fixes.

However, after testing v1.4.0, I can still reproduce the same core issue that was discussed in #42, #43, and #16. Although those issues were closed as completed, the underlying problem does not appear to be fully resolved.

1. Tunnel validation is still producing false positives

The most important requirement is that the local SOCKS5 proxy should only be exposed after Aether has verified that real traffic can pass through the tunnel.

At the moment, this validation is still unreliable in both MASQUE and WireGuard.

A successful scan or handshake does not necessarily mean the tunnel is actually usable. There are still cases where Aether reports the tunnel as healthy, opens the local SOCKS5 proxy, but no traffic can pass afterward.

The expected workflow should be something like this:

1. Discover a candidate endpoint.
2. Establish the tunnel.
3. Perform a real end-to-end validation.
4. Verify that actual traffic can be sent and received through the tunnel.
5. Only then expose the local SOCKS5 proxy.

If the validation fails, Aether should immediately discard that endpoint and continue searching instead of exposing a proxy that leads nowhere.

This behavior should be consistent across MASQUE, WireGuard, and gool.

2. Ironclad is solving the wrong problem

This is related to my previous suggestion in #43.

I still believe Ironclad should be a validation method, not a scan mode.

Today, selecting Ironclad means performing an extremely long scan where every candidate is subjected to expensive validation. This significantly increases connection time, yet it still cannot guarantee that the selected tunnel will remain usable after the SOCKS5 proxy is opened.

Instead, I think the workflow should be:

• Let the selected scan mode (turbo, balanced, thorough, stealth) quickly discover candidate endpoints.
• After candidates are found, apply the chosen validation method.
• If validation fails, discard those candidates and continue scanning for the next batch.

Separating discovery from validation would make the connection process much faster while keeping the same reliability goals.

At the moment, Ironclad mainly increases the connection time, but it still doesn't eliminate the false-positive cases described above.

I hope reopening this discussion helps, because from my testing the original issue is still reproducible despite the recent fixes.

Thanks again for all the work you've put into Aether.