The 'close' event on the raw IncomingMessage fires both when the request
body stream is fully consumed and when the underlying connection is
aborted. The handlerTimeout abort listeners treated every close as a
disconnect, so POST requests with a body had their request.signal
aborted as soon as the body finished streaming, and before the handler
had a chance to use it.

Guard both onAbort listeners with an aborted check on the
IncomingMessage so the signal only aborts when the client genuinely
disconnects, leaving normal body completion alone.

The onAbort handler unconditionally cleared the handler timeout timer
whenever the underlying request emitted 'close', including the normal
end-of-body close on POST requests. This caused the handler timeout to
be cancelled before the slow handler had a chance to time out, so
clients received no FST_ERR_HANDLER_TIMEOUT response.

Only clear the timer when the request was actually aborted, and add a
regression test covering a slow POST handler with a request body.