fix(eio,eio-client): handle close packets consistently across transports

[GiHoon1123]

Summary

Fixes #5286.

The polling transport already closes the connection when it receives a "close" packet, but the WebSocket transport silently ignored it and kept the connection running - on both the server and the client. This is inconsistent with the Engine.IO protocol, where close is a formal packet type (independent of the underlying WebSocket connection's own close frame), so any conformant implementation may send it over any transport.

Approach

Added the same check to the shared base Transport#onData() in both engine.io and engine.io-client, rather than duplicating polling's own override:

• On the server, this also covers the uWebSockets.js-based WebSocket transport for free, since it relies on the same base method and doesn't override onData().
• On the client, the close details now match the polling transport's existing wording ("transport closed by the server"), for consistency between transports.

Both fixes call the transport's real close procedure (close() / doClose() + onClose()), not just the internal state transition - an earlier version of this fix called onClose() directly (mirroring polling's own shortcut), but that leaves the underlying WebSocket connection open indefinitely, since polling's shortcut is safe only because each poll is a short-lived HTTP request that Node's HTTP server cleans up on its own, which doesn't apply to a persistent WebSocket connection.

The WebSocket path also avoids reporting the same close twice. When a close packet calls doClose(), the underlying WebSocket is closed deliberately; its onclose handler is cleared first so it cannot call Transport#onClose() a second time.

Out of scope

While investigating, two related gaps were found but intentionally left out of this PR to keep it focused on the reported issue:

• The WebTransport transport has the same underlying gap (it decodes and dispatches packets directly, bypassing onData() entirely), but it isn't mentioned in the issue and is disabled by default. Happy to follow up separately if maintainers want it addressed.
• This PR only reproduces the specific direction described in the issue (server sending a close packet, and the reverse). Nothing further intentionally deferred beyond WebTransport above.

Test plan

• New test: server closes the transport upon receiving a close packet from a WebSocket client
• New test: client closes the transport upon receiving a close packet from the server (matches the issue's reproduction), including asserting the close details match polling's wording
• Regression test: the client transport's onClose() method is called exactly once for a WebSocket close packet
• Reverted each fix individually (git stash on just that file) and confirmed the corresponding new test fails without it, then restored and reconfirmed it passes
• Checked directly (not just via the readyState field) that the underlying raw WebSocket connection is actually closed on both the server and client side, not just marked closed at the Engine.IO layer
• Existing engine.io suite passes for both protocol v4 and legacy v3 (EIO_CLIENT=3) - the client-side test is skipped under legacy v3 mode, since that mode exercises the separately-published engine.io-client-v3 package rather than the engine.io-client package touched by this PR
• Existing engine.io-client suite passes
• Targeted close-packet tests and format checks pass

[GiHoon1123]

Just checking in on this one. No rush at all, and I'd be happy to make any updates if there's anything else needed from my side.

[darrachequesne]

Thanks for the pull request. Please find my review notes below.

[darrachequesne]

I think onClose() will be called twice here with WebSocket:

• this.onClose({ description: "transport closed by the server" });
• and then in the "close" handler here:

  socket.io/packages/engine.io-client/lib/transports/websocket.ts

  Lines 83 to 86 in 3df3fed

  	this.onClose({
  	description: "websocket connection closed",
  	context: closeEvent,
  	});

Could you please check?

[GiHoon1123]

Thanks for catching this. I checked the WebSocket path and confirmed that the close packet called onClose() once, then ws.close() triggered the WebSocket onclose handler and called it again.

BaseWS.doClose() now clears that handler before closing the socket. The regression test counts Transport.onClose() calls and expects one; it failed with two calls before the change and passes now. The close reason and details checks remain in place.

The close-packet tests and format checks pass. The only local failure in the full Engine.IO run is the existing WebTransport test because the native webtransport.node module is not available in this environment.