ECN is lost on dual-stack sockets, in both directions #3

Receive

ecn::enable sets only IPV6_RECVTCLASS on a v6 socket. On a dual-stack v6
socket (no v6_only), IPv4 traffic goes through the kernel's IPv4 control
message path (udpv6_recvmsg -> ip_cmsg_recv_offset), which reports IP_TOS
only when IP_RECVTOS is set. IPV6_TCLASS is never emitted for that traffic.

Repro: v6 socket, IPV6_V6ONLY=0, receive_metadata<pktinfo, ecn>. Send an
ect0-marked datagram from a v4 socket to 127.0.0.1. Result: pktinfo present,
ECN absent.

The pktinfo comment already accounts for dual-stack sockets, so this looks like
an oversight.

Send

transmit_batch::build_control picks the family from to.is_v4(), so a v4-mapped
destination on a v6 socket gets an IPV6_TCLASS control message. The kernel
sends v4-mapped traffic through udp_sendmsg, whose ip_cmsg_send converts
IPV6_PKTINFO but skips every other SOL_IPV6 message. The marking is dropped
without an error.

Repro: v6 dual-stack sender, destination ::ffff:127.0.0.1, control
ecn = ect0. The v4 receiver sees not_ect.

Proposed fix

• ecn::enable on family::inet6 also sets IP_RECVTOS. Either ignore its
  failure or apply it only when the socket is not v6-only.
• On send, treat a v4-mapped v6 destination as v4 for ECN, so ecn::build emits
  IP_TOS. This needs a v4-mapped test on endpoint (IN6_IS_ADDR_V4MAPPED).
  quinn-udp does both.
• Check pktinfo::build for the same destination: ip_cmsg_send converts
  IPV6_PKTINFO, so it should already work. Add a test to pin that.

Acceptance

Loopback tests for both directions on a dual-stack socket, asserting the
codepoint round-trips.