Improve ECHONET Lite discovery robustness with passive probing and multi-response collection

[nao-pon]

Summary

This PR improves the robustness of ECHONET Lite device discovery in networks where multicast traffic may be unreliable (e.g. Wi-Fi mesh, router filtering, mixed L2 segments).

Two discovery enhancements are introduced:

1. Passive discovery probe for unknown hosts
2. Multi-response collection window for multicast discovery

These changes allow devices to be discovered even when standard multicast discovery does not work reliably.

---

Key Improvements

Passive discovery probe

If an INF / INFC notification is received from a host that does not yet have an instance list, a background unicast discovery probe is scheduled.

This allows discovery to succeed in cases where:

• multicast discovery packets are filtered
• multicast routing between Wi-Fi and wired segments is unreliable
• devices send notifications but do not respond reliably to multicast

To prevent discovery storms, probes are controlled using:

• _passive_probe_in_progress
• _passive_probe_cache
• per-result cache TTLs

A discovery callback is triggered only when the probe transitions a host from "unconfigured" to "configured".

---

Improved unknown host handling

Packets from unknown hosts now create a temporary state entry so the current packet can still be processed and discovery data extracted
immediately.

Active discovery is scheduled in the background unless the packet is already a Node Profile response.

---

Multicast discovery response window

Multicast discovery previously stopped after the first response.

Now responses are collected during a short window (_discovery_window) so multiple devices responding to the same discovery request can be properly detected.

---

Internal improvements

• Added _ensure_instance_state() helper to avoid duplicated instance structure initialization logic.

• Added _is_configured_host() helper to centralize the check for whether a host already has an instance list.

• Added packet decode protection to prevent malformed packets from breaking the receive loop.

• Added additional debug logging for discovery scheduling and probe results.

• Ignore packets originating from the local multicast interface.

---

Why this is needed

Some home networks (especially Wi-Fi mesh systems) partially filter multicast traffic between segments. In these environments:

• devices may still send INF notifications
• but multicast discovery may fail

The passive probe mechanism ensures these devices can still be discovered.

---

Compatibility

No breaking API changes.

All existing discovery behavior remains intact; the passive probe acts as an additional discovery path.

---

Tested with

• devices sending periodic INF notifications
• networks where multicast discovery is unreliable
• mixed wired / Wi-Fi network segments