docs(readme): say where the authorized_keys line actually goes

Step 2 of "Giving the container its own key for a peer" showed a correctly
narrowed authorized_keys line but never named the file it belongs in, and never
said which account's — the only mention of authorized_keys was an aside 35
lines further down about revoking one key per machine. A reader following the
steps had a public key, a line to construct, and nowhere to put it.

Now explicit: append to ~/.ssh/authorized_keys of the account named as `User`
in step 3, via a heredoc that shows `>>` rather than `>` (the truncation that
revokes every other key on that account), with `install -d -m 700 ~/.ssh` and
`chmod 600` so the file is created correctly the first time.

Adds the three failure modes that make a good key look broken, none of which
announce themselves on the client: the options prefix must be on the same
physical line as the key (a wrapped paste is the usual culprit), `ssh-copy-id`
cannot add that prefix at all so the line must be appended by hand, and sshd's
StrictModes silently ignores authorized_keys when the home directory, ~/.ssh or
the file is group- or world-writable — reporting it only in the peer's own log.

README.md

@@ -882,12 +882,28 @@ cat ~/.ssh-local/mypeer_devbox_ed25519.pub
 # ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEXAMPLE0000EXAMPLE0000EXAMPLE0000ex devbox-0d11ec7731c7
 ```
 
-**2. On the peer** — authorize it narrowly rather than bare:
+**2. On the peer** — append that public key to `~/.ssh/authorized_keys` **of
+the account you will log in as** (the `User` from step 3), narrowly authorized
+rather than bare:
 
-```
+```bash
+install -d -m 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`).
+
 `restrict` disables pty, agent/X11 and port forwarding; append
 `port-forwarding` and `permitopen="127.0.0.1:<port>"` after it if you need one
 specific tunnel. `from=` must list the **host's** addresses, not the