Explain when TestRequestTimeouts rightly gets 504 for a stopped client (closes #49)

The case where the client stops sending halfway answers 504 only if,
when the request timeout runs out, smallwebwaf has not yet connected to
the app and passed on the first bytes: until then it is waiting on the
app, and SPEC.md asks for 504. That normally takes a few milliseconds of
the 300 ms timeout, so the failure needs the test process to be held up
for about 300 ms at the start of the request; a pause injected there
reproduces it exactly. The code is right, and the test could only gain
margin from a longer timeout, which the issue rules out. The comment
records this for the next reader.

Judgement call: no change to the code or to what the test checks.

Model: opus-5-5

internal/proxy/timeouts_test.go

@@ -29,7 +29,10 @@ func TestRequestTimeouts(t *testing.T) {
 		env  map[string]string
 		// appTakesNothing has the app never read, while the client sends
 		// as fast as it can; otherwise the app reads, and the client
-		// stops sending halfway.
+		// stops sending halfway. smallwebwaf then waits on the client
+		// only once it has connected to the app and passed on the first
+		// bytes; a test process held up for shortTimeout before that
+		// gets 504, which is the right answer, and the case fails.
 		appTakesNothing bool
 		want            int
 	}{