feat(obs): distinguish one-way broadcast flow

The client previously reported "Broadcast traffic flowing" as soon as either
broadcast TX or RX was nonzero. During the MVP DHCP/ARP proof, one-way
broadcast is useful but weaker evidence than bidirectional broadcast.

Keep the existing healthy message for two-way broadcast, but report
outbound-only broadcast as a warning that the client is still waiting for a LAN
broadcast reply, and report inbound-only broadcast separately. This makes the
Windows client status lines more precise when DHCP is stuck.

Test Plan:
- cargo test -p lanparty-obs
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check
- git diff --cached --check

Refs: MVP Windows DHCP diagnostics

README.md

@@ -271,7 +271,8 @@ after bridging starts become visible in later status lines, preferring a
 non-link-local IPv4 address when Windows reports several TAP addresses. Each
 snapshot also emits short user-facing lines such as relay/gateway connection status,
 relay-route and TAP readiness warnings, DHCP address presence, relay RTT, and
-broadcast-flow confirmation when those signals are observed. Malformed frames
+broadcast-flow confirmation. One-way broadcast diagnostics distinguish frames
+sent toward the LAN from broadcast frames received back from the LAN. Malformed frames
 read from TAP, invalid or unauthorized source-MAC frames, L2 control-plane
 traffic, remote VLAN tags, DHCP server replies, IPv6 Router Advertisements, IPv6
 fragments, jumbo frames, and TAP frames whose encoded datagrams exceed the