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

sneak asked for every document to be audited for sentences that do not say what they mean. The byte limits now say which bytes count (response bodies, request bodies or both, as `SWW_BYTES_COUNT` says, WebSocket traffic included) and what passing one does. Other unclear or false sentences in `README.md`, `SPEC.md`, `EVALUATION.md` and `docs/` are rewritten.

Documents only. `REPO_POLICIES.md` is shared policy text and stayed out.

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

SPEC.md

@@ -22,8 +22,8 @@ to them.
   key or a token stays off until the operator supplies it.
 - It keeps a site answering while the part that decides is down, slow or
   restarting (see "Without an answer from `discriminator`").
-- It limits each client's requests and bytes per minute, hour and day. It bounds
-  the size and duration of every request and answer. It detects attacks.
+- It limits each client's requests and body bytes per minute, hour and day. It
+  bounds the size and duration of every request and answer. It detects attacks.
 - It bans abusers: briefly at first, for seven days on a clear sign of attack,
   and permanently when they keep at it.
 - It looks up each client's AS number and country. It can refuse whole countries
@@ -192,11 +192,12 @@ request log's `heuristic` field gives that name. `refusal_limit` and
     sent is removed.
 18. After the visitor's answer has ended, `rproxy` sends the report (see "The
     report"). `discriminator` then counts:
-    - For a request it allowed, the response bytes, the request bytes or both
-      are added to the byte counters, as `SWW_BYTES_COUNT` says. For a
-      WebSocket, what it carried each way counts once it closes. A client whose
-      total passes a byte limit times the percentage has broken that limit and
-      is banned (`byte_limits`). The response in progress is not cut off.
+    - For a request it allowed, the body bytes of the response, of the request
+      or of both are added to the byte counters, as `SWW_BYTES_COUNT` says. For
+      a WebSocket, what it carried each way counts once it closes. A client
+      whose total passes a byte limit times the percentage has broken that limit
+      and is banned (`byte_limits`). The request that broke it has already been
+      passed on whole; nothing is cut off.
     - For a request it allowed, the client's history and the anomaly counters
       are updated, and the alert thresholds are evaluated.
 
@@ -259,7 +260,8 @@ to a ban, each by its own rule:
       clear sign of attack bans it permanently at once.
 - A broken limit, one of:
     - a request over a rate limit;
-    - a response that takes the client's byte total past a byte limit;
+    - the bytes counted for a request and its response taking the client's total
+      past a byte limit;
     - more than `SWW_ERROR_BURST_THRESHOLD` refusals within a minute.
 
     The bans for a broken limit:
@@ -448,10 +450,15 @@ the same way.
 
 ### Byte limits, per client
 
-By default there is no minute limit, so a client can download in a burst at full
-speed. The hour limit defaults to 50 GiB and the day limit to 100 GiB. They
-allow several downloads of a few GiB each. A response's bytes are counted when
-it ends (see step 18).
+The byte limits count body bytes: the app's response bodies, the visitors'
+request bodies, or both, as `SWW_BYTES_COUNT` says. Headers are never counted.
+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 (see step 18). So the
+request that takes a client past a limit is passed on whole, and the ban refuses
+the client's requests from then on. By default there is no minute limit, so a
+client can download in a burst at full speed. The hour limit defaults to 50 GiB
+and the day limit to 100 GiB. They allow several downloads of a few GiB each.
 
 ### Lookup of AS number and country
 
@@ -953,7 +960,8 @@ which the metrics show. They reveal a widely distributed scraper, thousands of
 addresses at low rates each, which the per-client limits do not see. A low
 percentage for its `asn=` tag in `SWW_TAG_LIMIT_PERCENT` is the response.
 
-- Requests and bytes are counted per minute and per hour, for each of:
+- Requests and body bytes, as `SWW_BYTES_COUNT` counts them, are counted per
+  minute and per hour, for each of:
     - a client;
     - the surrounding netblock;
     - an AS number;
@@ -1263,9 +1271,9 @@ short.
 ### Answering in time
 
 `rproxy` stops waiting for `discriminator` after `SWRP_TIMEOUT_MS`, by default 2
-seconds, and `SWRP_DEFAULT_DISPOSITION` then decides. So at the defaults,
-`discriminator` answers a request well within that time, whatever the request
-and whatever its outside sources do.
+seconds, and `SWRP_DEFAULT_DISPOSITION` then decides. The longest a question
+waits on an outside source is `SWW_LOOKUP_TIMEOUT`, by default 800 milliseconds,
+well within that time.
 
 GeoJS is the only outside source a question can wait on. A question waits only
 when step 6 says so, and for at most `SWW_LOOKUP_TIMEOUT`, by default 800
@@ -1361,9 +1369,9 @@ answer.
 For a request it holds, `discriminator` writes the request's last log line (see
 "The log"). For a request it allowed, it first:
 
-- counts the bytes as `SWW_BYTES_COUNT` says, toward the client's byte limits at
-  the percentages it gave that request;
-- bans a client that passes a byte limit;
+- counts the body bytes `SWW_BYTES_COUNT` names, toward the client's byte limits
+  at the percentages it gave that request;
+- bans a client whose total passes a byte limit;
 - adds the request with its status to the client's history, the anomaly counters
   and the metrics.