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 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 the README's summary
of answers gave 408, which is only for a slow body.

Model: opus-5-5

SPEC.md

@@ -449,11 +449,15 @@ The settings, by group:
       waiting for the client to send more at that moment, and `504` if it was
       waiting for the app to take what it had.
     - Go's HTTP server, on which `smallwebwaf` is built, reads a request's line
-      and headers before `smallwebwaf` sees the request. A client that takes
-      longer than `SWWAF_CLIENT_REQUEST_TIMEOUT` to send them gets no answer:
-      the server closes its connection. Headers over
+      and headers before `smallwebwaf` sees the request. When
+      `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
       `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` are answered `431` by the server
-      itself. Neither request gets a line in the request log.
+      itself. None of these requests gets a line in the request log.
     - A WebSocket connection leaves these limits behind once it is upgraded: it
       stays open until either side closes it.
 - Lookup of AS number and country (R7). On by default through GeoJS, which needs