fix(discovery): resolve Windows broadcast discovery failure with ProactorEventLoop

[sfo2001]

Problem

Discovery fails silently on Windows systems due to ProactorEventLoop not properly handling the "<broadcast>" address, resulting in UDP packets not reaching the network interface. This particularly affects Windows systems with complex network configurations (multiple adapters, VirtualBox, WSL, etc.).

Fixes #61

Root Cause

The hardcoded "<broadcast>" string in discovery.py:39 works on Linux SelectorEventLoop but fails on Windows ProactorEventLoop, causing silent discovery failures where no bridges are found despite being present on the network.

Solution

• Replace hardcoded "<broadcast>" with programmatic broadcast address detection using netifaces
• Add robust fallback to 255.255.255.255 when interface detection fails
• Improve error handling around protobuf parsing
• Add comprehensive documentation and logging

Testing

Before (Windows)

Discovered bridges:

After (Windows)

Discovered bridges:
<Bridge 192.168.xxx.yy, UID=000000000022xxxxxxxxxxxxxxxxxxxx>

Cross-platform compatibility

• ✅ Windows: Now works with ProactorEventLoop
• ✅ Linux: Continues to work (tested on both platforms)
• ✅ Fallback: Graceful degradation when network detection fails

Changes

• Add netifaces dependency for network interface detection
• Enhance broadcast address resolution logic
• Improve error handling and logging
• Modernize type hints to Python 3.10+ standards
• Add comprehensive function documentation

Breaking Changes

None - maintains full backward compatibility.

[michaelarnauts]

I wonder if I can just use 255.255.255.255 instead of <broadcast>?