Fix ESP-IDF server-initiated discovery

[kyvaith]

Summary

Fixes two closely related discovery/connection problems seen with an ESP32-P4 ESP-IDF 6.0.1 device using Sendspin as an ESPHome component.

• Server-initiated WebSocket connections now arm client/hello from the accepted-connection path, not only from the later HTTP GET callback.
• If an integration leaves SendspinClientConfig::client_id empty, the client now falls back to the detected local network interface MAC address, matching the value advertised in device_info.mac_address.

Root cause

On ESP-IDF HTTPD, the WebSocket upgrade can complete and the connection can be accepted before the initial HTTP GET path reliably drives the existing on_connected_cb path. In that state the server gets a valid WebSocket connection, but no client/hello, so discovery appears flaky or the speaker appears only transiently.

For ESP32-P4 boards using hosted Wi-Fi, the active network interface MAC can also differ from the chip base MAC. Using the active interface MAC as the fallback client identity avoids requiring each integration to duplicate platform-specific MAC detection.

Validation

Tested on an ESP32-P4 ESPHome device with ESP-IDF 6.0.1:

• Verified inbound ws://device:8928/sendspin returns client/hello immediately after WebSocket upgrade.
• Verified client_id and device_info.mac_address use the hosted Wi-Fi STA MAC.
• Verified Music Assistant discovers the player and playback no longer drops after starting a stream.

Host CMake tests were not run locally because this Windows environment does not have a host C++ compiler on PATH. The available ESPHome firmware build using this branch compiled and ran on-device.

Documentation

No docs change: this is a transport/identity fallback fix and does not add a user-facing configuration option.

[kahrendt]

Thanks! These are good changes, and it has sparked (along with #70) my own re-design of the connection management. This is a good starting point for that work!