Docs: Explain transactional SSH hardening

README.md

@@ -41,9 +41,22 @@ question entirely:
 bash <(curl -fsSL https://git.gbrown.org/gib/Panama/raw/branch/main/boot) --server
 ```
 
-That command also works from a brand-new VPS's **root** login: it creates
-your user with sudo, moves the SSH key over, offers to harden sshd, and hands
-off to a normal install as that user.
+That command also works from a brand-new VPS's **root** login. It creates or
+reuses your sudo-enabled user, then copies a safe root key when it can or
+verifies the target key before offering SSH hardening. A verified target key
+means the target user owns `.ssh` with mode `0700` and `authorized_keys` with
+mode `0600`. SSH hardening is unavailable without a verified target key, and
+the install continues without it.
+
+When you accept hardening, Panama makes an atomic same-directory drop-in,
+validates the complete SSH configuration with `sshd -t`, then reloads the
+detected SSH unit. If validation or reload fails, it restores the previous
+drop-in and validates and reloads that restored configuration; recovery that
+cannot complete stops the handoff and prints the manual recovery command. The
+fixture contracts exercise these branches. No real daemon reload runs under
+`panama test --safe`, so that suite is not live-host proof.
+
+After that, it hands off to a normal install as the new user.
 
 `install` asks its questions first and then runs the stages in `setup/scripts/`
 in order, without stopping again:
@@ -198,7 +211,7 @@ docs/           Settings reference, and the design specs behind the work
 
 ## Tests
 
-186 of them, under `tests/`. `tests/contracts.manifest` classifies every
+187 of them, under `tests/`. `tests/contracts.manifest` classifies every
 contract by the capabilities it needs. Run the hermetic set, or grant a
 specific external capability when automation needs it: