Fix six README sentences (closes #565)

Rewrite the six sentences the documents check failed, each checked
against the code. The Sign-in limits section now opens with its rule.
The recovery routine's sentences say it resumes a delivery: it queues a
pending one at once, but gives a retrying one the rest of its wait.

Model: opus-5-5

README.md

@@ -47,7 +47,7 @@ identifier of its own to the request, so make your targets tolerate a duplicate.
 
 ## Getting Started
 
-You need the Go version named in `go.mod`, and Docker for the checks.
+You need the Go version named in `go.mod`.
 
 ```bash
 git clone https://git.eeqj.de/sneak/webhooker.git
@@ -57,9 +57,8 @@ DATA_DIR=../webhooker-data make dev
 ```
 
 `DATA_DIR` is where webhooker keeps its databases. It defaults to
-`/var/lib/webhooker`, so point it at a directory you can write to. On a host
-without Docker, `make build` writes the program to `bin/webhooker`, and running
-that file starts webhooker.
+`/var/lib/webhooker`, so point it at a directory you can write to. `make build`
+writes the program to `bin/webhooker`. Running that file starts webhooker.
 
 The first start creates the `admin` account and prints its password once, in a
 ruled box on standard output:
@@ -107,9 +106,9 @@ sooner after 24 hours without use, unless `SESSION_IDLE_TIMEOUT` says otherwise.
 On the webhook list at `/hooks`, **New Webhook** asks for **Name**, an optional
 **Description** and **Retention (days)**. Events older than the retention period
 are deleted, along with their deliveries. The default is 30 days. `0` keeps
-events forever. The form also has an **HTTP target URL** field and an
-**Archive** checkbox; each creates that target with the webhook. Every new
-webhook gets one entrypoint, described as `Default entrypoint`.
+events forever. Filling in **HTTP target URL** creates an `http` target with the
+webhook. Ticking **Archive** creates an archive target. Every new webhook gets
+one entrypoint, described as `Default entrypoint`.
 
 ### Entrypoint URLs
 
@@ -198,9 +197,9 @@ Read it with `docker logs` and the name upaas gave the container.
 webhooker speaks plain HTTP. It does not handle TLS, the encryption behind
 HTTPS: it holds no certificate and accepts no HTTPS connections. The reverse
 proxy holds the certificate and reaches webhooker over a private address. A bare
-host is a host without Docker. On a bare host that is loopback, the address only
-this host can reach. For the image it is the Docker bridge, the private network
-Docker puts containers on.
+host is a host without Docker. On a bare host the private address is loopback
+(`127.0.0.1`), which only this host can reach. For the image it is the Docker
+bridge, the private network Docker puts containers on.
 
 Four things must be right.
 
@@ -371,13 +370,13 @@ writes it. The reverse proxy's access log does hold it, in the request path.
 
 ### Sign-in limits
 
-The password is checked first, and only a failed sign-in is counted. A correct
-password is never answered `429`. Failures are counted per client and submitted
-username. From the fifth failure within a minute, each failure is answered
-`429`. At most two password checks run at once; a request that gets no turn
-within 5 seconds is answered `503`. So guessing speed is bounded by the limit of
-two checks at a time, not by the failure count. Choose a long random `admin`
-password, or rate-limit `POST /pages/login` at the reverse proxy.
+From the fifth failure within a minute, each failure is answered `429`. Only
+failures are counted. A correct password is never answered `429`. Failures are
+counted per client and submitted username. At most two password checks run at
+once; a request that gets no turn within 5 seconds is answered `503`. So
+guessing speed is bounded by the limit of two checks at a time, not by the
+failure count. Choose a long random `admin` password, or rate-limit
+`POST /pages/login` at the reverse proxy.
 
 ### Delivery destinations
 
@@ -433,10 +432,11 @@ sends them on in the background, and SQLite holds everything in between.
 
 The receiver stores the event and one pending delivery per active target in one
 database write, then queues the deliveries. Background workers run them and
-record each attempt. At start, a recovery routine queues again every delivery
-left `pending` or `retrying`. It then runs every minute. Each run sends again a
-`retrying` delivery the engine is not working on, and a `pending` one that has
-sat untouched for 15 minutes. So a stop or a crash loses no delivery.
+record each attempt. At start, a recovery routine resumes every delivery left
+`pending` or `retrying`. It then runs every minute. Each run resumes every
+`retrying` delivery that the engine is not already handling. It also resumes a
+`pending` delivery that has sat untouched for 15 minutes. So a stop or a crash
+loses no delivery.
 
 The main database holds configuration. Each webhook has its own event database,
 so writes for one webhook never wait on another webhook's database. The program