README and SPEC say when a client too slow to send its request line or headers is answered 400 (closes #138)

When SWWAF_CLIENT_REQUEST_TIMEOUT runs out partway through a line, Go's
server reads the part that arrived, a carriage return without its line
feed included, as the whole line. If that part cannot be read as a line,
it answers 400; otherwise it closes the connection without an answer.
The README's "Request log" and SPEC's size and time limits said such a
client always gets no answer, and both documents' summaries of answers
gave 408 for any slow client, when it is only for a slow body.

Model: opus-5-5

README.md

@@ -1047,8 +1047,9 @@ mostly with `400`, and a request line and headers slower than
 `SWWAF_CLIENT_REQUEST_TIMEOUT`. When that time runs out, the server takes what
 has arrived of the line it is reading for the whole line, and answers `400` if
 that is not a line it can read, as for a request line cut before the end of its
-HTTP version or a header cut before its colon. Otherwise, as for a client that
-stops at the end of a line, it closes the connection without an answer.
+HTTP version, a header cut before its colon, or a line cut between its carriage
+return and line feed. Otherwise, as for a client that stops right after a line
+feed, it closes the connection without an answer.
 
 ### Sending the log to a syslog server
 

SPEC.md

@@ -437,10 +437,10 @@ The settings, by group:
       the app sends it and the client receives it.
     - When a limit is passed before the response has started, `smallwebwaf`
       answers itself: `413` for a request body that is too large, `408` for a
-      client that is too slow, `502` for a response that is too large, `504` for
-      an app that is too slow. A request that announces a body larger than its
-      limit is refused before anything reaches the app. Once the response has
-      started it can only be cut off, and the connection is closed.
+      client too slow to send its body, `502` for a response that is too large,
+      `504` for an app that is too slow. A request that announces a body larger
+      than its limit is refused before anything reaches the app. Once the
+      response has started it can only be cut off, and the connection is closed.
     - Since a request body streams through, each side can hold up the other: a
       slow client slows the send to the app, and an app slow to take the body
       slows the client's send. So while a request body is still on its way, a
@@ -453,9 +453,10 @@ The settings, by group:
       `SWWAF_CLIENT_REQUEST_TIMEOUT` runs out before they have all arrived, the
       server takes what has arrived of the line it is reading for the whole
       line, and answers `400` if that is not a line it can read, as for a
-      request line cut before the end of its HTTP version or a header cut before
-      its colon. Otherwise, as for a client that stops at the end of a line, it
-      closes the connection without an answer. Headers over
+      request line cut before the end of its HTTP version, a header cut before
+      its colon, or a line cut between its carriage return and line feed.
+      Otherwise, as for a client that stops right after a line feed, it closes
+      the connection without an answer. Headers over
       `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` are answered `431` by the server
       itself. None of these requests gets a line in the request log.
     - A WebSocket connection leaves these limits behind once it is upgraded: it