fix(proto): canonicalize remote IP in early_discard_packet's peer check (noq#738)

[cuzic]

Closes #738.

Problem

4bae6edd (the hotfix posted in #738) canonicalizes the local_ip
comparison in Connection::early_discard_packet, to handle dual-stack
sockets that report a peer as an IPv4-mapped-IPv6 address
(::ffff:a.b.c.d) on one side of the comparison and a plain IPv4 address
on the other. We applied it and confirmed on a real Android device
(WiFi + cellular) that it is not sufficient on its own — open_path()
with an explicit local_ip still gets abandoned with ValidationFailed.

The remote comparison a few lines above the one 4bae6edd touches
has the exact same problem, and is not canonicalized:

if network_path.remote != known_path.network_path.remote && !peer_may_probe {

An incoming datagram's reported remote SocketAddr can compare unequal
to the known path's remote purely due to mapped-vs-plain representation,
so early_discard_packet silently drops every packet on that path before
it ever reaches PATH_RESPONSE / frame processing — same failure mode as
the local_ip bug, just one comparison earlier in the same function.

Fix

Mirror the existing local_ip fix: canonicalize both sides of the
remote comparison with IpAddr::to_canonical() before comparing.

This is the minimal, surgical fix — one comparison site, matching the
style of 4bae6edd. See #784 for an alternative that canonicalizes
once at FourTuple::new() construction time instead, which also covers
a few other latent comparison sites (Endpoint's
HashMap<FourTuple, ConnectionHandle> routing table,
is_probably_same_path, PATH_CHALLENGE on-path detection, OBSERVED_ADDRESS
matching, peer migration detection) that weren't yet observed failing in
our testing but share the same root cause.

Testing

• Includes the regression test from the noq-738 branch
  (noq-proto/src/tests/multipath.rs::open_path_with_explicit_local_ip),
  adapted to build its ManyToManyRouting via add_client_route/
  add_server_route instead of from_routes — from_routes now rejects
  the duplicate server_addr this test intentionally uses (invariant
  added by feat(proto): use path idle timeout for validation when opening a new path #721 after the regression test was originally written).
  Fails on unpatched main, passes with this fix.
• cargo test -p noq-proto: 388 passed, 0 failed (full suite, not just
  the new test).
• Verified on a real Android device: Secondary (local_ip: None)
  established, then PhysicalWifi/PhysicalCellular (local_ip
  explicit) both validate on the first attempt instead of retrying
  3x and getting abandoned:

  opening path "physical-wifi" -> <redacted>:45823 (local_ip=Some(192.168.10.80), attempt 1/3)
  path "physical-wifi" established: id=PathId(2)
  opening path "physical-cellular" -> <redacted>:45823 (local_ip=Some(10.209.235.90), attempt 1/3)
  path "physical-cellular" established: id=PathId(3)
  

[cuzic]

Closing in favor of #784, which now also covers the additional comparison sites beyond early_discard_packet (is_probably_same_path, PathResponses::push, OBSERVED_ADDRESS matching, peer-migration detection) — see the comparison writeup on the issue.

#784 has been refactored per @divagant-martian's review: the comparison logic now lives as FourTuple::same_remote(&self, other: &Self) / FourTuple::same_local_ip(&self, other: &Self) methods instead of free-standing functions.