fix(ws): do not panic in EspWebSocketClient::drop on destroy failure

[SAY-5]

Problem

#648 fixed the unwrap() on esp_websocket_client_close inside
EspWebSocketClient::drop, but left the matching call to
esp_websocket_client_destroy as:

impl Drop for EspWebSocketClient<'_> {
    fn drop(&mut self) {
        if let Err(e) = esp!(unsafe { esp_websocket_client_close(self.handle, self.timeout) }) {
            log::warn!("WebSocket close failed during drop: {e:?}");
        }

        esp!(unsafe { esp_websocket_client_destroy(self.handle) }).unwrap();  // can still panic
    }
}

A Drop impl must not panic. On ESP-IDF targets built with
panic = "abort" any panic in Drop aborts the whole application
without unwinding, so this is worse than a missed error.

The failure is reachable in practice: new_raw constructs the client
before calling esp_websocket_client_start(), so a failed start returns
Err via ? and drops a client whose transport was never established,
which is exactly the scenario where destroy can fail. Reported in
#653.

Fix

Apply the same treatment already used for close: log the error and
swallow it. Same warning style so log noise stays consistent.

-     esp!(unsafe { esp_websocket_client_destroy(self.handle) }).unwrap();
+     if let Err(e) = esp!(unsafe { esp_websocket_client_destroy(self.handle) }) {
+         log::warn!("WebSocket destroy failed during drop: {e:?}");
+     }

Fixes #653