Allow searching for bridges on more than one network

[michaelarnauts]

The discovery request went to the limited broadcast address (<broadcast> = 255.255.255.255). That is not sent out over every interface: the operating system does a routing lookup and picks exactly one, so a bridge behind another interface never sees the request.

$ ip route get 255.255.255.255
broadcast 255.255.255.255 dev eth0 src 192.168.1.59

This is what breaks discovery in #61, where VirtualBox, WSL and a few disconnected WiFi adapters compete with the real network card. It is not Windows specific though, and ProactorEventLoop has nothing to do with it: a Linux machine with multiple interfaces fails in exactly the same way, which is also why --host has always worked for these users.

discover_bridges() now accepts the broadcast address of every network that should be searched:

bridges = await discover_bridges(broadcast_addresses=["192.168.1.255", "10.0.0.255"])

Sending to a subnet directed broadcast address makes the routing work in our favour: 192.168.1.255 is routed over the interface that owns that subnet, so no interface binding or address enumeration is needed here. Home Assistant already knows these addresses through network.async_get_ipv4_broadcast_addresses(), which follows the adapters the user enabled, so the integration can pass them without pulling in a dependency like netifaces (as #62 proposed) or ifaddr. The cli learned a --broadcast option that can be repeated.

Nothing changes when no addresses are passed, we broadcast like we always did.

Two smaller things in the same file:

• A bridge that answers more than one of our requests is now only reported once, deduplicated on its uuid.
• Responses that arrive after the discovery finished are ignored. They used to call set_result() on the completed future (InvalidStateError) and mutate the list that was already handed to the caller.
• A discovery that finds nothing logs that it found nothing, instead of failing silently.

Tested against a real bridge: --broadcast 192.168.1.255 --broadcast 10.0.0.255 finds it once, plain discover and --host are unaffected, and a search on the wrong subnet only now logs No bridges responded to the discovery request. The Windows side of #61 still needs @sfo2001 to confirm.

Refs #61

🤖 Generated with Claude Code