docs(readme): use mkdir -p instead of install -d for the peer's ~/.ssh

`install -d -m 700 ~/.ssh` was correct but wrong for the audience. This snippet
gets pasted onto an arbitrary peer — a NAS, a router, a BSD box — and `install`
is not in POSIX, so it is not guaranteed to be there. `mkdir -p` + `chmod` is
POSIX, present everywhere, and self-evidently idempotent to a reader deciding
whether it is safe to run on a machine that already has keys.

Behaviour was checked rather than assumed, on both coreutils and BSD/macOS
`install`: on an existing ~/.ssh it exits 0 and leaves authorized_keys intact
in content and mode, but it also silently chmods the directory (755 -> 700).
Desirable here, yet invisible in a doc — which is the second reason to prefer
the explicit two-step form, and why the surrounding text now states outright
that re-running is safe on an already-configured peer: mkdir -p is a no-op, the
chmods only tighten, and appending never touches keys already listed.

Verified the whole block end-to-end against a fresh HOME and one with a
pre-existing 755 ~/.ssh and an older key: 700/600 in both cases, older key
preserved, new line appended.

README.md

@@ -887,22 +887,25 @@ the account you will log in as** (the `User` from step 3), narrowly authorized
 rather than bare:
 
 ```bash
-install -d -m 700 ~/.ssh
+mkdir -p ~/.ssh && chmod 700 ~/.ssh
 cat >> ~/.ssh/authorized_keys <<'KEY'
 from="192.168.1.0/24,192.168.4.0/24,10.8.0.7",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEXAMPLE0000EXAMPLE0000EXAMPLE0000ex devbox-mymachine
 KEY
 chmod 600 ~/.ssh/authorized_keys
 ```
 
-Use `>>`, never `>` — one stray truncation revokes every other key on that
-account. The options prefix must sit on the **same physical line** as the key,
-comma-separated with no spaces: a paste that wrapped is the likeliest reason a
-key that looks right is refused. `ssh-copy-id` cannot add that prefix, so
-append by hand (or let it copy the bare key and edit the line afterwards). If
-authentication still fails with no clear reason, suspect permissions — sshd's
-`StrictModes` silently ignores `authorized_keys` when the home directory,
-`~/.ssh` or the file itself is group- or world-writable, and says why only in
-the peer's own log (`journalctl -u ssh`, `/var/log/auth.log`).
+Both lines are safe on a peer that is already set up: `mkdir -p` is a no-op
+when the directory exists, the `chmod`s only tighten, and appending never
+touches keys already listed. Use `>>`, never `>` — one stray truncation
+revokes every other key on that account. The options prefix must sit on the
+**same physical line** as the key, comma-separated with no spaces: a paste
+that wrapped is the likeliest reason a key that looks right is refused.
+`ssh-copy-id` cannot add that prefix, so append by hand (or let it copy the
+bare key and edit the line afterwards). If authentication still fails with no
+clear reason, suspect permissions — sshd's `StrictModes` silently ignores
+`authorized_keys` when the home directory, `~/.ssh` or the file itself is
+group- or world-writable, and says why only in the peer's own log
+(`journalctl -u ssh`, `/var/log/auth.log`).
 
 `restrict` disables pty, agent/X11 and port forwarding; append
 `port-forwarding` and `permitopen="127.0.0.1:<port>"` after it if you need one