fix: end a listing whose peer stopped reading

The idle deadline covered RETR and the command stage only, so a LIST,
NLST or MLSD that stopped being read had nothing to end it: the server
retried its failing writes until the client gave up, and the session
stayed open holding the queued send buffer. Observed on an ESP32-S3
with internal DRAM exhausted, 415 rounds before the run was stopped by
hand.

Listings refresh the deadline whenever the peer takes bytes, so
covering them ends only the ones that stopped moving. STOR refreshes
nothing yet and stays out.

Author: srgg

FtpServer.cpp

@@ -448,13 +448,15 @@ uint8_t FtpServer::handleFTP() {
 
 		// Out of the chain above, whose tail this was: a running transfer always took its own
 		// branch, so the deadline was never reached — and doRetrieve() now waits a stalled peer
-		// out instead of aborting, leaving nothing else to end it. RETR refreshes this deadline
-		// as it sends; the other types never do, so bounding them would kill them mid-progress.
-		const bool in_retrieve = (transferStage == FTP_Retrieve);
-		if (cmdStage > FTP_Client && (transferStage == FTP_Close || in_retrieve)
+		// out instead of aborting, leaving nothing else to end it. RETR and the listings both
+		// refresh this deadline as they send, so it ends only what stopped sending; STOR does
+		// not refresh it and stays out of scope rather than die mid-progress.
+		const bool in_transfer = (transferStage == FTP_Retrieve || transferStage == FTP_List
+				|| transferStage == FTP_Nlst || transferStage == FTP_Mlsd);
+		if (cmdStage > FTP_Client && (transferStage == FTP_Close || in_transfer)
 				&& !((int32_t) (millisEndConnection - millis()) > 0)) {
 			DEBUG_PRINTLN(F("Timeout"));
-			if (in_retrieve) {
+			if (in_transfer) {
 				// NOT closeTransfer(): that answers 226. abortTransfer() replies 426 and fires
 				// FTP_TRANSFER_ERROR, which releases what the app took.
 				abortTransfer();