handlerLogger's responseRecorder and handlerWriteTimeout's writeTimeoutWriter
both wrap http.ResponseWriter but implement neither http.Flusher nor Unwrap().
Any handler that flushes mid-response has that flush silently dropped, and its
output only reaches the client when the handler returns.
That defeats the stated purpose of writeTimeoutWriter, whose own comment says it
exists so one can "write long responses, splitted in chunks, without causing
timeouts": the deadline is reset per Write(), but nothing ever leaves the buffer
until the end.
Found while adding a server-sent-events endpoint: events written and flushed at
t=0.4s only reached the client at t=2.2s, when the handler returned.
Adding Flush() plus Unwrap() (so http.ResponseController can reach through) fixes
both. The new test drives a real listener through both wrappers and reads while
the handler is still blocked, so it fails on the current code by hitting the read
deadline.
loggerWriter was shadow-copying every response byte into a bytes.Buffer
to report the body size, causing the entire response to be accumulated
in memory for the lifetime of each request. Replace the buffer with a
plain int counter since dump() only ever reported the byte count anyway.
