Offer to bring the keys an ssh_config points at

An import that recorded a key path and left every host asking for a password was
an import whose result did not connect. The answer to that was a manual paste per
key, which is the sort of thing people do once and then stop importing.

So there is a tick, and it starts off. With it off nothing changes: an
IdentityFile becomes a note and the host asks for a password. With it on, IMPORT
reads each host's first IdentityFile out of ~/.ssh, stores it in the vault
encrypted like any other key, and binds the host to it.

Three things about how it is drawn are load-bearing rather than tidy. It is a
default nobody arrives at by accident. The sentence beside it names the directory
rather than saying "your keys", because that is what somebody is agreeing to. And
nothing is read during SCAN — tick it, read what it says, untick it, and no
private key has been opened. This is the only place the application opens key
material out of a directory the user did not point at file by file, and the whole
of what makes that acceptable is that it took a deliberate press.

One vault key per file, however many entries named it: an ssh_config pointing
twelve hosts at one id_ed25519 is the ordinary shape, and twelve copies would be
twelve things to rotate and eleven to forget. A file whose material is already in
the keychain is bound to rather than stored again, which is what makes running
the import twice harmless.

What cannot be read off a disk is a passphrase, so a protected key arrives
without one — and the report under the button names those files rather than
leaving a host to fail at connect time with a message about a malformed key.
Telling them apart means decoding for OpenSSH's own container, whose cipher name
is the first field inside the base64 rather than anything in the armour, and that
is the format ssh-keygen has written by default for years. The 88 base64
characters it decodes need 66 bytes, not 64: with the smaller span every
protected key came back unprotected, which the tests now pin.

A path that is not on this machine leaves its host imported and unbound, exactly
as it would have been with the tick off, and is named in the same report. A
config carried from another machine is the ordinary case, not an error.

docs/design-import-gaps.md

@@ -210,8 +210,10 @@ saved, and there is no frame on the terminal data plane that would carry a chang
 **Three things the design did not ask for and this build now has.** A key can be generated in the client
 rather than pasted in (`SshKeyGenerator`, and the `openssh-key-v1` container is written by hand — see
 `OpenSshKeyWriter` for why there was no alternative and why it is written unencrypted). Hosts can be
-imported from `~/.ssh/config` (`DodoSSH.Client.Import`; it reads no key material, and `ProxyJump` is
-recorded as intent because the SSH layer still has no jump hosts). And the file-transfer screen takes drag
+imported from `~/.ssh/config` (`DodoSSH.Client.Import`; `ProxyJump` is recorded as intent because the SSH
+layer still has no jump hosts, and the private keys the config names come in **only behind a tick that
+starts off** — the one control in this application that opens key material out of a directory the user did
+not point at file by file, which is why nothing is read until IMPORT is pressed). And the file-transfer screen takes drag
 and drop in four directions — remote to Explorer is the one that does not ship, because it needs a virtual
 file the platform layer cannot supply; see `docs/manual-checks.md`.