Make SSH ProxyCommand helpers like cloudflared work reliably #11

Hermes Desktop already works well for the normal SSH-first cases it is built around: direct hosts, SSH aliases, localhost, LAN/public IP, VPN, and Tailscale, as long as standard ssh from the Mac can reach the host.

This issue is about a narrower case: SSH setups that depend on a local ProxyCommand helper such as cloudflared.

In these setups, the app launches /usr/bin/ssh and relies on the local SSH config, but the helper binary also needs to be resolvable from the app environment. If cloudflared is only available in an interactive shell PATH and not in the GUI app context, SSH can fail even though the same config appears to work from Terminal.

Why this matters:

• Cloudflare Tunnel / Access SSH is a legitimate workflow
• users should not need to abandon the app just because their SSH route depends on a local helper binary

Likely fix direction:

• improve support for SSH config flows that rely on local ProxyCommand helpers
• make local helper resolution more reliable from the app context
• improve user-facing guidance when a helper like cloudflared is missing from the effective PATH

Practical workaround today:

• use the absolute path to cloudflared in ProxyCommand
• or make sure cloudflared is installed in a path visible to GUI-launched apps, not only to an interactive shell

So this remains a valid issue, but it is best understood as a ProxyCommand helper environment case rather than a general SSH compatibility problem.