docs: scope server kernel-timestamp claim to this crate's server

irtt-client can talk to any IRTT-compatible peer, not only this
repo's own irtt-server, and has no way to know what clock source
produced a peer-reported wall-clock endpoint. Restrict the
kernel-receive-timestamp-preference claim to when the peer is
this crate's own Linux irtt-server; state plainly that another
peer's reported value is used as-is otherwise.

README.md

@@ -185,7 +185,7 @@ Useful measurement fields include:
 
 Adjusted RTT can be negative when server processing exceeds the measured raw RTT. One-way delay estimates can be negative because of clock skew between the client and server.
 
-On Linux, `sd_us` and `rd_us` (and the underlying one-way delay samples) prefer kernel-captured send/receive timestamps over userspace timing where the platform and socket support them, reducing the effect of scheduling and queuing delay on these measurements. This is a best-effort fallback: unsupported or implausible kernel timestamps fall back to userspace timing. `raw_rtt_us` always uses userspace timing and is unaffected; `adjusted_rtt_us`/`effective_rtt_us` can still shift slightly, since server processing time is derived from the same server receive endpoint.
+On Linux, `sd_us` and `rd_us` (and the underlying one-way delay samples) prefer a kernel-captured timestamp over userspace timing for this client's own send/receive endpoint where the platform and socket support it, reducing the effect of scheduling and queuing delay on these measurements. The peer's reported endpoint gets the same preference when it is this crate's own `irtt-server` on Linux; against another IRTT-compatible server, whatever wall-clock value it reports is used as-is. This is a best-effort fallback: unsupported or implausible kernel timestamps fall back to userspace timing. `raw_rtt_us` always uses userspace timing and is unaffected; `adjusted_rtt_us`/`effective_rtt_us` can still shift slightly, since server processing time is derived from the same server receive endpoint.
 
 Default table output prints a final summary after completed finite runs and interrupted continuous runs when the run policy permits it. CSV, TSV, and JSON Lines output do not print this summary.
 

crates/irtt-client/src/event.rs

@@ -354,13 +354,16 @@ pub struct OneWayDelaySample {
     /// wall time when both are available. The client send endpoint is the
     /// correlated Linux kernel TX timestamp for this send when one is
     /// available and plausible for this send, and the userspace post-send wall
-    /// time otherwise. The server receive endpoint is the server's kernel
+    /// time otherwise. The server receive endpoint is whatever wall time the
-    /// receive timestamp when one is available and plausible, and its
+    /// peer reported; against this crate's own `irtt-server` on Linux, that is
-    /// userspace receive wall time otherwise. `RttSample::raw` is unaffected
+    /// its kernel receive timestamp when one is available and plausible, and
-    /// and remains a userspace monotonic measurement, but `adjusted` and
+    /// its userspace receive wall time otherwise. Against another
-    /// `effective` can still shift: when the session negotiated wall-clock
+    /// IRTT-compatible peer, the client has no way to know which clock source
-    /// timing rather than monotonic, server processing time is derived from
+    /// produced it. `RttSample::raw` is unaffected and remains a userspace
-    /// this same server receive endpoint.
+    /// monotonic measurement, but `adjusted` and `effective` can still shift:
+    /// when the session negotiated wall-clock timing rather than monotonic,
+    /// server processing time is derived from this same server receive
+    /// endpoint.
     pub client_to_server: Option<SignedDuration>,
     /// Server-to-client delay.
     ///