Socket.IO v3 transport ordering change obscures fallback diagnosis in debug logs

Context

Socket.IO v3 reversed the default client transport priority to ["websocket", "polling"], making WebSocket the first attempt and only falling back to long-polling after a handshake failure. When corporate proxies block the WebSocket upgrade, the client enters a reconnect loop that emits repeated socket.io:transport debug entries.

Problem

No dedicated transport-fallback event or log marker signals the switch from WebSocket to polling. Engineers must infer the transition from the pattern of a transport error followed by a transport success line, which can be misread as a successful WebSocket connection if only the final entry is inspected. The default 10-second fallback timeout is also not prominent in the main documentation, so behavior varies across deployments.

Goal

Establish a reliable, log-only method to confirm that a client has fallen back to polling without enabling verbose debug output that floods high-traffic environments.

What minimal log pattern or configuration change definitively indicates a transport fallback in Socket.IO v3 and v4? Does setting a custom transports array alter the emitted log sequence in a way that removes the ambiguity? Is there a documented event or hook that can be subscribed to for programmatic detection of the fallback?