fix(pairing): configure IPv4 multicast interfaces on multihomed hosts

[lolinyaanyaamoe]

Summary

Configure explicit IPv4 multicast interfaces for both the pairing mDNS publisher and resolver. This fixes invitation discovery on multihomed hosts where the peer-facing Ethernet interface is not the operating system's default multicast interface.

Reproduction and root cause

Two computers (Windows and macOS) are connected directly by Ethernet on the same IPv4 subnet, while each computer retains a separate Internet connection. Invitation-code pairing fails with either computer acting as the sponsor.

The publisher previously enumerated interface addresses for Discoverer::with_addrs, but advertising an address does not select the multicast interfaces used to discover that advertisement. Neither pairing adapter supplied with_multicast_interfaces_v4, leaving discovery dependent on the default interface.

Changes

• Add a shared MdnsInterfaceSnapshot helper, captured separately at the start of each publish/resolve operation.
• Deduplicate addresses and exclude loopback, unspecified, and multicast addresses.
• Feed eligible IPv4 addresses to with_multicast_interfaces_v4 on both publisher and resolver; keep the publisher's advertised addresses consistent with the same filtering policy.
• Retain IpClass::Auto, existing error source chains, and default-interface behavior when interface enumeration fails. The new diagnostics record counts/error categories, not interface addresses or names.
• Add regression tests and a design note explaining the scope and lifecycle.

This replaces the publisher-only enumeration helper; it does not introduce a second pairing flow.

Compatibility and scope

No changes to invitation format, service name, authentication, encryption, storage, resolver timeout, relay/cloud policy, or post-pairing transport. No dependency updates.

Interface selection is a per-operation snapshot, not continuous interface monitoring. IPv6 multi-interface behavior, arbitrary VPN/WireGuard topologies, firewall restrictions, and network hot-plug are not claimed as fixed or validated.

Validation

Previously completed when this commit was prepared on the Engine revision pinned by Desktop v1.0.1 (3f3eef7450e06013c3178b716eee9d5a3c419349, Engine v1.1.0-rc.20):

• Four pairing mDNS tests passed, covering address selection/filtering and existing publisher/resolver behavior.
• Engine workspace/all-target compile checks, formatting, and architecture/privacy checks passed.
• Custom macOS arm64 and Windows x64 Desktop v1.0.1 builds completed. Windows build: https://github.com/lolinyaanyaamoe/UniClipboard/actions/runs/36815170063
• The reporter confirmed that the original equivalent fix, delivered in a Desktop 1.0.0-alpha.17 custom build, resolved the Windows/macOS direct-Ethernet multi-NIC pairing failure. This is not a claim of a full device/network matrix or a fresh runtime validation against today's upstream main.

This PR contains only commit 5b7d59c0073f45413bd608f1c08f71a72c4968da (six files). Subsequent local HarmonyOS bindings, multicast socket experiments, query cadence changes, and online invitation policy adaptations are intentionally excluded.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8b32dbfe-8908-4848-b902-380a963eaa3c

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}