Discover and prefer Qortium peers on the local network

[QuickMythril]

Summary

Add bounded automatic discovery of Qortium nodes on the same LAN so authenticated nodes can establish a direct local connection and move QDN content over that path.

This preserves the product request from Q-Support record 02d249b0f84017d63235dc47, “LAN quick sync.” The reporter published a Q-Tube video on one wired computer, opened it on another wired node behind the same router, and still waited minutes because the nodes did not appear to discover or use each other directly.

Current Qortium behavior

Qortium Core already:

• listens for direct chain and QDN connections on local interfaces when direct IP transport is enabled;
• supports manual LAN endpoints through initialPeers and initialDataPeers;
• keeps local-address gossip scoped to local peers;
• derives a data-peer endpoint from an authenticated chain handshake that advertises QDN capability; and
• prioritizes direct or low-hop QDN providers, then uses measured RTT, queue load, and cooldown state.

The missing piece is automatic LAN node discovery. UPnP only discovers a router for public port mapping; Core has no mDNS or bounded multicast peer-discovery service.

Proposed sequence

1. Manual two-node proof: configure two Qortium nodes on one LAN, publish a unique multi-chunk resource on node A, and prove node B completes it through the authenticated LAN chain/data path.
2. Bounded discovery: add a versioned link-local multicast probe with unicast replies, TTL 1, local-source validation, chain fingerprint and node ID checks, rate limits, candidate caps, expiry, and normal authenticated handshakes before trust.
3. Use existing QDN selection first: verify the authenticated local holder wins through the current hop/RTT/load logic. Add only a bounded first-chunk exploration rule if an unmeasured LAN peer otherwise never gets sampled.
4. Settings and diagnostics: expose an explicit LAN discovery setting plus protected state for probes, candidates, authenticated local peers, expirations, and rejections.

Discovery must not advertise API or gateway ports, credentials, account data, I2P destinations, or public addresses. Remote and I2P peers remain fallbacks.

Blocked prerequisite

Implementation is intentionally on hold until a Mac or another second LAN node is available for the manual two-node proof. That test must distinguish discovery failure from serving or provider-selection failure before a protocol is added.

Acceptance criteria

• Two nodes on one LAN can discover one another without a preconfigured peer address.
• Only the discovered chain endpoint enters the candidate pool; QDN capability is trusted only after the normal authenticated chain handshake.
• An uncached multi-chunk QDN resource is proven to arrive over the LAN path with byte-identical validation.
• Discovery is link-local, bounded, rate-limited, expiring, and disabled for incompatible transport/QDN modes.
• Public peers never receive private LAN addresses through peer gossip.
• Remote/I2P fallback, invalid-data cooldown, restart, sleep/wake, DHCP change, VPN/multi-interface, and discovery-disabled behavior are covered.