Make nearby pairing resilient across Windows interfaces

[Chris-ObtuseAI]

What changed

• enumerate active non-loopback, non-link-local, non-point-to-point IPv4 interfaces
• send laptop discovery to multicast, global broadcast, and every unique directed LAN broadcast
• join the owner multicast group on each active LAN address
• bound each side with its own local pairing lifetime instead of trusting the other device's wall clock
• retain the existing X25519/HKDF/AES-GCM transcript code, owner window, request bounds, rate limits, and encrypted invitation
• document the physical failure, corrected behavior, and candidate-3 evidence boundary

Why

A physical laptop remained on "Looking for your main PC" even though the owner listener and private-network firewall rule were healthy. The old worker trusted Windows to choose one interface for global broadcast and multicast. VPN and virtual adapters can win that routing decision, hiding the real Wi-Fi or Ethernet LAN. The pre-authentication path also silently rejected clocks differing by more than 30 seconds.

User impact

The normal flow remains Find my fabric on the laptop and Add machine on the owner. Rampage now searches every active LAN path automatically, and incorrect device clocks cannot strand discovery or extend enrollment authority.

Validation

• cargo fmt --all -- --check
• cargo check --workspace --all-targets
• cargo test --workspace (22 desktop-native tests plus the full Rust campaign)
• cargo clippy --workspace --all-targets -- -D warnings
• pnpm check (desktop 18, edge 2, TypeScript SDK 12; all builds)
• Ruff, mypy, intelligence 17 tests, Python SDK 11 tests
• RustSec baseline: 0 vulnerabilities; 18 reviewed warnings
• scripts/Assert-RampageVersion.ps1 -Tag v0.3.1 (9 surfaces)
• scripts/Smoke-RampageInstaller.ps1: install/uninstall 0, six payloads, shortcuts verified, controller/intelligence ready, one signed node/offer, no leaked sidecars

Physical two-machine pairing and Remote Assist remain explicitly pending the candidate-3 tag-bound package.