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)

docs/request-log.md

@@ -145,20 +145,22 @@ Every one of these lines has:
   included. It is left out when rate limiting did not count the request. It
   holds:
     - `minute`, `hour` and `day`: requests;
-    - `minute_bytes`, `hour_bytes` and `day_bytes`: bytes.
+    - `minute_bytes`, `hour_bytes` and `day_bytes`: the body bytes
+      `SWW_BYTES_COUNT` names, in that window.
 
     A count can have a fraction (see "Counting method" in
-    [`SPEC.md`](../SPEC.md)). The bytes of an allowed request are counted when
-    its report comes. So on the `decision` line, the bytes are without this
-    request's.
+    [`SPEC.md`](../SPEC.md)). The bytes counted for an allowed request and its
+    response are added when its report comes. So on the `decision` line, the
+    three byte totals leave them out.
 
 - `limit_hit`: the limit broken:
     - `minute`, `hour` or `day` for a rate limit;
     - `minute_bytes`, `hour_bytes` or `day_bytes` for a byte limit;
     - `error_burst`.
 
-    A request whose bytes broke a limit was passed on whole, so its `action`
-    stays `forward`. Only its `report` line gives that limit.
+    When the bytes counted for a request and its response break a limit, the
+    request has been passed on whole, so its `action` stays `forward`. Only its
+    `report` line gives that limit.
 
 - `rule_ids`: the rule file rules that matched, in order, up to the one that
   refused.