s3: report a peer that went away as ClientDisconnected, not IncompleteBody (#10511)

* s3: report a peer that went away as ClientDisconnected, not IncompleteBody

A streaming PUT whose body ends early is always reported as IncompleteBody
(400). That collapses two cases with opposite causes: the peer vanished
mid-upload, and the peer sent fewer bytes than it promised while still
connected. The first points at the network path, the second at the client,
and once merged they cannot be told apart from the logs.

Split out ClientDisconnected (499) and select it when the request context
shows the peer is gone. The upload itself keeps running on a background
context so chunks still finish, which means cancellation races the read
error; a missed signal degrades to IncompleteBody exactly as before.

* s3: note what request-context cancellation is taken to mean

weed/s3api/s3err/s3api_errors.go

@@ -160,6 +160,9 @@ const (
 
 	// Truncated request body (fewer bytes than Content-Length)
 	ErrIncompleteBody
+
+	// Peer went away before the request body was fully received
+	ErrClientDisconnected
 )
 
 // Error message constants for checksum validation
@@ -317,6 +320,13 @@ var errorCodeResponse = map[ErrorCode]APIError{
 		Description:    "You did not provide the number of bytes specified by the Content-Length HTTP header.",
 		HTTPStatusCode: http.StatusBadRequest,
 	},
+	// 499 has no RFC; it is nginx's code for a client that went away, and is what
+	// log pipelines already recognise for this case.
+	ErrClientDisconnected: {
+		Code:           "ClientDisconnected",
+		Description:    "The client disconnected before the request body was fully received.",
+		HTTPStatusCode: 499,
+	},
 
 	ErrInvalidPart: {
 		Code:           "InvalidPart",