How to go about tracking down this error?

OK I see your confusion: with the instrumentation in ipdHandler, line 16 (above) is commented out ///* so you don't see the packets reported where it is known there is more data to come i.e. ipdHandler (more) as opposed to ipdHandler (empty). This was just to avoid flooding the logging. If you want to see everything as it arrives just remove the first // on line 16 (above) and you'll get the lot.

So if I understand you right: socketserver.c would not use CHUNK to define a fixed buffer length for incoming data but just take whatever netRecv gets from netCallbacks.recv with no maxlen specified, as it will always return everything in sockData[sckt].

If I have this right, then sockData[sckt] will still be buffering around 6-8K (in your log above: 7063 bytes on the first recv) as recv only gets to run every ~500ms while serial data is arriving. Is there a way to make this more frequent, say once every ~100ms to keep the buffering down? Even a 6-8K buffer will stretch available memory.

P.S. the deltaTime in the logging is only meaningful on the second call to recv onwards.

My other crazy plan, that I will ask a few question of @tve to qualify if it is worth the effort, is to to run Espruino on the ESP8266 which implements the SDK's flow control for TCP sockets espconn_recv_hold and espconn_recv_unhold. Then write some javaScript to run on the ESP8266 paired with a module on the Pico that effectively proxies the ESP8266 Wifi module across the serial connection between the two devices, along with a kind of proxy for the netCallbacks on the Pico side paired with the net and sockets modules on the ESP8266 side. Waddayoureckon? Crazy huh! If this can be made to work, we get to use the memory on the ESP8266 for some of the buffering and we get TCP flow control.