Describe what the connected-UDP modules are instead of forecasting their wiring

The header comments on the connected-peer socket and on its drain thread both
said the fast path was not yet wired into the node tick, and that a follow-up
would do it. It has been wired at both ends for some time: the rx loop calls
activate_connected_udp_sessions, which spawns PeerRecvDrain. A reader deciding
whether the connected-UDP send path is live got the wrong answer from the first
comment they met.

Both files already carry module docs describing what they are, so the forecast
comments are deleted rather than reworded. The dead_code allowances they
justified go with them: clippy with -D warnings passes without either, so they
were suppressing nothing, and while they sat there they would also have hidden
whatever went dead next in those modules.

src/transport/udp/connected_peer.rs

@@ -1,8 +1,3 @@
-// The connected-UDP fast path is infra-ready but not yet wired into the
-// encrypt-worker dispatch site (a follow-up PR will refcount-clone the
-// socket into each FmpSendJob). Keep the API surface in tree.
-#![allow(dead_code)]
-
 //! Connected per-peer UDP socket.
 //!
 //! One of the levers boringtun uses to hit 2.5–3.2 Gbps on a real

src/transport/udp/peer_drain.rs

@@ -1,7 +1,3 @@
-// Paired with `connected_peer.rs`: dormant in this PR until the
-// activation handler is wired into the node tick (follow-up).
-#![allow(dead_code)]
-
 //! Recv-side drain thread for a per-peer connected UDP socket.
 //!
 //! Once a UDP socket is `connect()`-ed to a peer, Linux and Darwin