Say which bytes the byte limits count, and what passing one does (closes #203)

Documents only. The byte limits and byte anomaly thresholds count body
bytes, as SWW_BYTES_COUNT chooses them, with WebSocket traffic each way,
once a response has ended; the request that passes a limit is not cut
off and the client is banned. README.md, SPEC.md and docs/ now say so,
and no longer call a response's bytes the request's. Also made plain:
rate limits, the refusal threshold, SWRP_MAX_REQUEST_TIME_MS,
SWW_LOOKUP_SOURCE, the metrics' byte series, and the SPEC.md claim about
answering within SWRP_TIMEOUT_MS. EVALUATION.md is audited too; its
survey facts and date are unchanged.

Model: fable-5-1 (first audit); opus-5-5 (rework)

docs/settings.md

@@ -98,6 +98,8 @@ between the two (see "The image's command" below).
 
 ## Request rate limits, per client
 
+The request past one of these limits is refused, and the client is banned.
+
 - `SWW_RATE_LIMIT_PER_MINUTE` (default `120`, 2 a second): the most requests a
   client may make in a minute. A count or `off`. The default leaves room for a
   person opening two pages at once with an empty cache, up to 60 files each.
@@ -120,11 +122,21 @@ between the two (see "The image's command" below).
 
 ## Byte limits, per client
 
+These count body bytes, never headers. What the visitor sent over a WebSocket
+counts as request bytes, and what the app sent as response bytes. The bytes
+counted for a request and its response are added to the client's total once the
+response has ended. The request that takes a client's total past a limit is not
+cut off; the client is banned.
+
 - `SWW_BYTES_LIMIT_PER_MINUTE` (default `off`), `SWW_BYTES_LIMIT_PER_HOUR`
   (default `50G`) and `SWW_BYTES_LIMIT_PER_DAY` (default `100G`): the most bytes
-  counted for a client in each window. A size or `off`.
-- `SWW_BYTES_COUNT` (default `both`): which body bytes the byte limits count:
-  `response`, `request` or `both`.
+  counted for a client in each window, a size or `off`: response bodies, request
+  bodies or both, as `SWW_BYTES_COUNT` says. The request that passes the limit
+  is not cut off, and the client is banned when its response ends.
+- `SWW_BYTES_COUNT` (default `both`): what the byte limits and the byte anomaly
+  thresholds count: `response`, the app's response bodies; `request`, the
+  visitors' request bodies; or `both`. What the visitor sent over a WebSocket
+  counts as request bytes, and what the app sent as response bytes.
 
 ## Lookup of AS number and country
 
@@ -198,8 +210,9 @@ between the two (see "The image's command" below).
   a range. So does a directive that removes or changes rules as the file loads,
   such as `SecRuleRemoveById`, since none of the Core Rule Set's rules is loaded
   yet. It has no `_FILE` form.
-- `SWW_ERROR_BURST_THRESHOLD` (default `30`): the most refusals of one client in
-  a minute (see "Attack detection" in `SPEC.md`). A count or `off`.
+- `SWW_ERROR_BURST_THRESHOLD` (default `30`): the most refusals a client may get
+  in a minute from a rule file, a trap path or the Core Rule Set, a count or
+  `off`. The next one bans the client (see "Attack detection" in `SPEC.md`).
 
 ## Ban lengths, response and scope
 
@@ -276,9 +289,10 @@ between the two (see "The image's command" below).
 
 ## Anomaly thresholds
 
-Each scope has four thresholds: the most requests and the most bytes counted in
-a minute and in an hour. Requests are counts, bytes are sizes. Each is `off` by
-default. The four thresholds per client are:
+Each scope has four thresholds: the most requests and the most body bytes
+counted in a minute and in an hour. The bytes are those `SWW_BYTES_COUNT` names.
+Requests are counts, bytes are sizes. Each is `off` by default. The four
+thresholds per client are:
 
 - `SWW_ANOMALY_CLIENT_REQUESTS_PER_MINUTE`;
 - `SWW_ANOMALY_CLIENT_REQUESTS_PER_HOUR`;