[Mikhail Yaskou (mikhail-yaskou)]

When the WebSocket port is occupied at startup, _handleWSError creates a replacement WSServerWithOriginCheck without registering its connection, error, or listening handlers. The replacement can bind successfully, but the original startup promise never settles, so ServerGrouping.openServer() never calls _connected() and Show Preview never opens. A second collision can also emit an unhandled error. The EADDRNOTAVAIL branch has the same missing handlers.

Restart through _startWSServer(basePath) in both recoverable error branches and chain its result to the original promise. Every bind attempt then registers the original handlers, and successful startup or failure propagates back to the caller.

Validation on Linux against the actual bundled _startWSServer method from Live Preview 0.4.20, using real TCP blockers and a real WebSocket client:

• Original method, one held port: replacement bound at the next port, original promise remained pending, connection handler did not run.
• Proposed method, two consecutive held ports: startup resolved and the connection handler ran at the third port.
• Proposed method, unavailable starting host plus one held loopback port: reset to the default host, advanced past the blocker, resolved startup and handled the connection.