eitri is the only thing that can dial an eitri guest: SSHArgv never emits ssh_config

open   by a73x

eitri is the only thing that can dial an eitri guest. `SSHArgv`
(internal/cli/sshcmd.go:34) builds a complete system-ssh argv — gate hop as an
explicit ProxyCommand, pinned CA known_hosts, strict checking, the namespaced
<tenant>.<vm> connect name — and then execs it. Every input is already resolved
there; none of it is ever emitted.

So `eitri ssh <vm> [remote command]` works, and nothing else does. rsync, scp,
sftp, git-over-ssh, sshfs, VS Code Remote and any agent harness that shells out
to `ssh user@host` cannot reach a guest, because they build their own argv and
have no way to learn the gate hop.

Proposal: teach eitri to emit the same connection as ssh_config — a `Host`
block with the ProxyCommand, UserKnownHostsFile, IdentityFile and StrictHostKeyChecking
that SSHArgv already computes — so the existing tools work unmodified. Shape is
open: `eitri ssh --print-config`, an Include-able file `eitri init` writes, or
both. SSHArgv stays the single source of the argv shape; the emitter is a second
rendering of the same resolved Env, and the existing table tests should cover
both renderings together so they cannot drift.

Worth a cheap spike first: rsync invokes `<rsh> <host> <remote-cmd>` and
GIT_SSH_COMMAND is invoked the same way, which is coincidentally the exact shape
of `eitri ssh <vm> <cmd>`. `rsync -e "eitri ssh"` and
`GIT_SSH_COMMAND="eitri ssh"` may already work by accident. Unverified. If they
do, that is worth documenting either way, and it does not cover scp/sftp/sshfs
or anything that parses ssh_config.

Why it matters now: this is the barrier to getting code onto a guest, and it is
not a storage problem. It blocks the durable-workspace work from being useful,
and it is what would let an external agent harness route its tools into an eitri
guest with zero eitri-specific code.