fix(server): use kernel receive time for wall timestamps

An echo reply's receive wall timestamp now prefers the kernel arrival
reading the Linux listener captured, where that reading is plausible for
the datagram it describes. That removes socket-queue and runtime wakeup
latency from the upstream one-way delay a client computes, and it is the
only thing the observation is allowed to change.

The runtime reaches the core through a crate-private entry point taking
the optional observation as an explicit per-datagram argument; the public
ServerCore::handle_datagram is unchanged in signature and in behavior, and
both run one implementation. There is no "next receive timestamp" side
channel and no clock wrapper.

ClockSample stays one paired userspace instant: the preferred wall value
is carried beside it on the classified echo, never inside it. Lifecycle,
rate and maximum-duration policy remain on received_at.mono_ns, midpoints
remain the mean of the paired userspace samples, and no monotonic instant
is estimated from a wall reading. A reading that does not convert, that is
later than the core's own sample, or that lags it by more than one second
falls back to the userspace wall; it is never a reason to drop a datagram.

crates/irtt-server/src/runtime.rs

@@ -229,14 +229,21 @@ impl Server {
                         len,
                         peer,
                         reply_source,
-                        // Observed by the transport and deliberately unused.
-                        // The core samples its own receive instant, and this
-                        // is where a kernel-observed arrival time stops until a
-                        // follow-up change decides how it should enter the core
-                        // — feeding it in here would change protocol timing.
-                        kernel_rx_timestamp: _kernel_rx_timestamp,
+                        // Handed to the core with the datagram it describes, as
+                        // an explicit per-datagram input. The core samples its
+                        // own receive instant regardless and decides whether
+                        // this one is usable; nothing here judges it, and there
+                        // is no "next receive" state between the two.
+                        kernel_rx_timestamp,
                     } = received;
-                    if let Some(reply) = self.core.handle_datagram(peer, &self.recv_buffer[..len])? {
+                    // `reply_source` stays on this side of the boundary: which
+                    // of the host's addresses a request arrived on is transport
+                    // state, not session policy.
+                    if let Some(reply) = self.core.handle_received_datagram(
+                        peer,
+                        &self.recv_buffer[..len],
+                        kernel_rx_timestamp,
+                    )? {
                         if !self.prepare_reply_traffic_class(reply.traffic_class()) {
                             continue;
                         }