[Feature request]: Managed Aether/Psiphon entry hops for proxy chains

[sae13]

Related problem

Some networks cannot reach an existing VLESS, Hysteria, Shadowsocks, or other profile directly, while that same profile works when its connection is first routed through Aether or Psiphon. The desired paths are:

user -> Aether -> selected PattN configuration -> Internet
user -> Psiphon -> selected PattN configuration -> Internet

Upstream projects:

• Aether: https://github.com/CluvexStudio/Aether
• Psiphon Docker: https://github.com/swarupsengupta2007/psiphon-docker
• Psiphon core used by that image: https://github.com/Psiphon-Labs/psiphon-tunnel-core

Issue #23 mentions related Aether-to-Psiphon/Onion ideas, but it combines several unrelated requests. This issue isolates a concrete entry-hop chaining feature with testable acceptance criteria.

Describe the solution you would like

Please add Aether and Psiphon as managed entry-hop profile types or presets that can be placed before an existing PattN profile, proxy chain, or subscription/group.

Suggested behavior:

1. Offer separate Aether entry hop and Psiphon entry hop presets.
2. Let either preset be selected as the first hop for one profile, a proxy chain, or every profile in a subscription/group.
3. Start and stop the helper process/container, validate its local SOCKS/HTTP endpoint, wait for readiness, and show logs/health in PattN.
4. Route the next profile's connection through that local proxy and prevent the helper process from being captured by PattN's own TUN/system proxy.
5. Preserve proxy-side DNS where possible and clearly expose TCP/UDP limitations.
6. Support an advanced use an already-running local proxy mode.
7. Prefer native helper binaries on supported platforms; Docker can be an optional Psiphon backend rather than a requirement.

Aether exposes a local SOCKS5 proxy and ships binaries for Windows, Linux, and macOS. The referenced Psiphon image exposes SOCKS and HTTP proxy ports. PattN therefore would not need to reimplement either protocol: it could manage the helper and integrate its local proxy into PattN's existing proxy-chain model.

Alternatives considered

• Manually run Aether or the Psiphon container, add its local SOCKS endpoint as a profile, and construct a chain. This works in principle but requires manual installation, port and process management, readiness checks, loop avoidance, and recovery after helper failure.
• Reimplement Aether or Psiphon inside PattN. This would be substantially more complex and is not necessary if a managed local-proxy adapter is used.
• Use Aether/Psiphon as the final exit only. That does not satisfy the use case: they are needed as the first hop, while the selected PattN configuration remains the next hop/final proxy.

Acceptance criteria

• Both chains can be created from the GUI.
• A single entry-hop preset can be applied to an entire subscription/group.
• URL/latency tests use the full chain rather than bypassing the entry hop.
• Helper crashes or readiness failures are visible and do not silently fall back to a direct connection.
• TUN and system-proxy modes do not create routing loops.
• Process/container cleanup occurs when the profile is stopped or PattN exits.

Automatic transport discovery and profile persistence

Please also add an Auto-scan transports option to both managed entry-hop presets.

When enabled, PattN should:

1. Enumerate the connection methods supported by the selected helper and current platform instead of requiring the user to choose one blindly.
   • For Aether, scan its available MASQUE HTTP/3, MASQUE HTTP/2, WireGuard, and applicable nested modes/options.
   • For Psiphon, delegate protocol discovery and selection to the official Psiphon core wherever possible rather than maintaining a stale hard-coded protocol list in PattN.
2. Probe candidates with bounded per-candidate and overall timeouts.
3. Mark a method as reachable only after a real data-plane request succeeds through the helper's local SOCKS/HTTP proxy; process startup, handshake success, or an open local port alone must not count.
4. Offer First reachable and Best available policies. The first stops at the first validated method; the second tests all candidates and chooses the fastest stable result.
5. Persist the winning transport/mode and its non-secret parameters in the Aether/Psiphon entry-hop profile, show it in the GUI, and try it first on the next start as the last-known-good method.
6. Rescan automatically after configurable consecutive failures or a network change, and provide a manual Rescan transports action.
7. If all methods fail, report the failure and per-candidate diagnostics. Do not silently bypass the entry hop or leak traffic through a direct fallback.
8. Scope cached results to the current network where feasible, since the working method may differ across ISPs and interfaces.

Expected flow:

Start profile
  -> scan supported Aether/Psiphon methods
  -> validate real traffic through each local proxy
  -> select first reachable or best available
  -> save the winning method in the entry-hop profile
  -> start: winning entry hop -> selected PattN configuration

This is needed because the reachable transport can change by ISP, network, location, or time, and users often cannot know beforehand which method will work.