docs: qualify RTT-unaffected claim to raw RTT only

adjusted_rtt_us/effective_rtt_us are derived in part from
server-reported processing time, which is computed from the same
server receive endpoint the client_to_server one-way-delay field
documents as kernel-preferred. Only raw RTT is guaranteed to stay
on userspace monotonic timing; say so precisely instead of
claiming RTT in general is unaffected.

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. RTT always uses userspace timing and is unaffected.
+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.
 
 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

@@ -356,8 +356,11 @@ pub struct OneWayDelaySample {
     /// available and plausible for this send, and the userspace post-send wall
     /// time otherwise. The server receive endpoint is the server's kernel
     /// receive timestamp when one is available and plausible, and its
-    /// userspace receive wall time otherwise. RTT is unaffected and remains a
-    /// userspace monotonic measurement.
+    /// userspace receive wall time otherwise. `RttSample::raw` is unaffected
+    /// and remains a userspace 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.
     ///