WebSocket client: respect write capacity during upgrade

[meganetaaan]

Summary

Make embedded:network/websocket/client respect the socket's reported writable capacity while sending the HTTP Upgrade request.

The client currently records onWritable(count), but sends the complete Upgrade request in a single write(). A TLS socket may initially expose less writable capacity than the request, especially when custom headers make the handshake larger. In that case the connection fails before the Upgrade request reaches the server.

Root cause

The "connecting" branch builds the HTTP Upgrade request and immediately passes the entire ArrayBuffer to the socket. Unlike WebSocket frame writes after the connection is established, this path does not compare the request size with #writable.

On an ESP32-S3, a deliberately enlarged 12,370-byte Upgrade request received writable capacities of 5,648, 2,771, 2,771, and 1,180 bytes. The existing implementation attempted the full 12,370-byte write and failed before opening the WebSocket. With this change, the same request was sent in four writes and the WSS connection opened successfully.

Changes

• Retain the unsent request bytes while the handshake is in progress.
• Add a sendRequest state that writes at most the currently reported capacity.
• Transition to receiveStatus only after the complete Upgrade request has been sent.
• Leave the established WebSocket frame write path unchanged.

Validation

• Added a deterministic TestMC regression using a fake socket that reports a 64-byte write capacity.
• The test verifies that no write exceeds the reported capacity, that the request is split across multiple writes, and that the final \r\n\r\n is sent.
• The negative control without this change fails on the first oversized write; the patched client passes.
• Built the TestMC target for ESP32-S3.
• Validated the complete TLS/WSS handshake on an M5Stack CoreS3 running Moddable 9.0.0 and ESP-IDF 6.0.2.