ssh: fall back to exec relay when streamlocal forwarding is unavailable (embedded sshds) (#7)

* fix: fall back to an exec relay when streamlocal forwarding is unavailable

Some sshds accept a direct-streamlocal channel open (ssh's -L unix-socket
forward) and then never service it: the channel opens, zero bytes flow, and
every connection attempt eventually fails with "api closed before response:
ping". Plain ssh exec channels and TCP forwarding are unaffected — only
streamlocal is dead against these servers (embedded Go sshds fronting
container/VM workspaces are the case this was diagnosed against).

For ssh hosts, add an exec-relay transport for the API connection: a remote
stdio<->unix-socket bridge run over a plain ssh exec channel, one relay
process per API connection — the same shape as the existing docker-exec
relay, one level up the transport stack. The remote bridge command is
socat when present, else a small python3 fallback (bidirectional,
unbuffered, binary-safe, half-close-correct).

`api_transport = "auto"` (new, default) tries the streamlocal forward first
and switches to the exec relay on failure, remembering the choice for the
daemon's lifetime so a host that needed the fallback isn't re-probed on
every reconnect. `"socket"` and `"exec"` pin one transport and skip the
probe entirely.

* fix: make the transport probe free, give the exec relay its own socket, don't stick on one failure

---------

Co-authored-by: niko <nikokristanto24@gmail.com>