fix: transfer outcomes, a stalled peer, and listings that never end

[srgg]

The Problem

Four defects in the existing transfer paths, all found while serving files from an SD card over WiFi on an ESP32-S3, all reproduced on hardware.

1. A transfer that moves no bytes, or finishes within one millisecond, tells the application nothing: closeTransfer() emits its terminal callback from inside a condition that guards a division. An application holding something for the duration of a transfer never learns it may let go.
2. Three paths answer 226 for a transfer that failed — a zero-byte socket write, a peer that vanishes mid-file, and an upload that goes silent — and a short write loses data outright, because file.read() has already advanced the cursor past the bytes that never left.
3. doRetrieve() ends the transfer when a socket write returns zero. Zero does not mean the peer left: NetworkClient::write() returns it after exhausting its own retry budget, which happens whenever the WiFi driver is momentarily short of a transmit buffer, and clears within seconds. A 2.9 MB file ended at 32 KB, and resuming returned the same block again.
4. A LIST, NLST or MLSD entry goes out as up to nine separate print() calls, and the idle deadline covers RETR and the command stage only. A window that shuts mid-entry leaves half a line in the stream with the directory cursor already past it, so every entry after it is unparseable — and nothing ends a listing whose peer stopped reading. With internal memory exhausted, 415 rounds of failing writes were captured before the run was stopped by hand.
5. abortTransfer() fires FTP_TRANSFER_ERROR for whatever stage was running, including a listing. A listing has no file and no byte count of its own, so an application watching transfers receives the name and total of whichever RETR ran before it — reachable today by disconnecting a client mid-LIST, which reaches abortTransfer() through disconnectClient().

The Fixes

One commit each, in the order they must be read.

Fix 1 and 2 — report every transfer outcome, and report the end at all

Every ending funnels through abortTransfer(), which takes the reply line so 450, 552 and 426 Data connection closed survive instead of being replaced by a second 226. The terminal callback moves out of the guarded branch, so it fires for an empty transfer too. A short write rewinds the file cursor by the unsent remainder.

Fix 3 — ride out a peer whose window shuts

The transfer waits instead of ending: the file cursor rewinds, the idle deadline moves only when bytes actually leave, and the deadline check moves out of the if/else chain in handleFTP() where a running transfer could never reach it.

Fix 4a — render a listing entry once, resume it if the peer takes part

The entry is rendered into a member buffer and written once, with the remainder kept pending until the peer takes it — the shape doRetrieve() uses for a short write. An entry counts toward the closing 226 N matches total only once all of it is away, and a line too long for the buffer keeps its CRLF rather than merging into the next entry. Both the retrieve path and the listing path write through one accountant, so neither can send bytes without moving the idle deadline, nor move it without sending any. This also removes the nine-calls-per-entry cost: each call spends the socket's full write budget again (WIFI_CLIENT_MAX_WRITE_RETRY × WIFI_CLIENT_SELECT_TIMEOUT_US, ten seconds on ESP32 Arduino), so a peer that stopped reading held one handleFTP() call for about ninety seconds.

Fix 4b — end a listing whose peer stopped reading

The idle deadline covers FTP_List, FTP_Nlst and FTP_Mlsd. That is safe only because of Fix 4a: listings now refresh the deadline whenever the peer takes bytes, so it ends the ones that stopped moving and leaves the ones still delivering. STOR refreshes nothing yet and stays outside rather than risk ending an upload mid-progress.

Fix 5 — a listing reports no transfer of its own

abortTransfer() fires FTP_TRANSFER_ERROR only for FTP_Retrieve and FTP_Store.

This is a deliberate behaviour change to an existing path: the callback line predates this branch, and gating it is what stops a listing from reporting a foreign file name and byte count. Routing dataConnected() through abortTransfer() in Fix 1 and 2 widened the reach of the defect, which is why it is fixed here rather than left.

Nothing automated guards it, and the callback was not observed on hardware — the bench application ignores FTP_TRANSFER_ERROR unless a transfer is live.

Trade-offs

• Listing entries are rendered with snprintf into a fixed buffer instead of streamed with print(). That costs FTP_LIST_LINE_SIZE bytes of RAM per server instance — derived from FTP_FIL_SIZE and FTP_CRED_SIZE, the limits this header already declares, plus the date field and the widest a long prints — and it is what makes a partial write resumable, which streaming cannot be once the directory cursor has moved.
• The idle deadline now ends listings. A client that opens a data connection and reads nothing for FTP_TIME_OUT gets 426 where it previously got a server that waited forever; that is the intent, and progress of any size defers it.

How to verify

Serve a directory over FTP and pull a listing and a file while the client reads normally: the listing and the file are unchanged, byte for byte. Then stop reading mid-transfer and watch the session end with 426 after FTP_TIME_OUT instead of retrying indefinitely.

Verified on an ESP32-S3 with an SD card: NLST and LIST both return all 108 entries in the same format as before, and a 41.7 MB file retrieves byte-identical to the same file fetched by name. Not verified: the SPIFFS, LittleFS, FFAT, FatFs and SdFat backends compile-only paths — this hardware exercises STORAGE_SD_MMC with NETWORK_ESP32, and the other backends were changed mechanically, in the same shape.