Pin mDNS sends per interface and rank LAN addresses (#235)

Two multi-interface bugs made discovery invisible and pairing QRs wrong
on Macs with a VPN, VM bridge, or Thunderbolt link up:

- mdns.ts joined the multicast group per interface but never pinned the
  send side, so announcements, group answers, and goodbyes left on
  whichever single interface the kernel routed 224.0.0.251 to — often
  a utun the phone is not on. Every group send now runs through one
  serialized queue that calls setMulticastInterface per advertised
  address before each send (serialized because the pin redirects every
  subsequent send on the socket), skipping interfaces that vanished
  between enumeration and send. Unicast answers still route normally.

- lanAddresses() returned networkInterfaces() in enumeration order,
  and the pairing QR embeds the first non-tailnet entry — which could
  be bridge100 or vmnet. Addresses are now ranked: en0/en1/... first,
  unrecognized real interfaces next, tunnel/bridge/mesh names
  (utun, tun, tap, bridge, vmnet, awdl, llw, feth) kept but last.

The responder gains a structural ResponderSocket seam so the pinning
contract is asserted against a recording socket in tests; CI cannot
route the real group. Ranking comparator mutation-checked.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>