refactor(client): capture send timestamp before socket call

Record the send timestamp immediately before the socket operation to include local enqueue overhead in RTT measurements, providing more conservative latency data for consumers.

crates/irtt-client/src/client.rs

@@ -201,9 +201,8 @@ impl Client {
             payload: vec![],
         };
         let packet = encode_echo_request(&request, self.config.hmac_key.as_deref())?;
-        self.socket.send(&packet)?;
-
         let sent_at = override_ts.unwrap_or_else(ClientTimestamp::now);
+        self.socket.send(&packet)?;
 
         let session = self
             .session

docs/IMPLEMENTATION_PLAN.md

@@ -546,8 +546,8 @@ Steps:
 1. Assert Active phase
 2. Check if duration exceeded (if finite mode) → if so, transition to Draining
 3. Encode echo request with current sequence number, connection token
-4. Call `socket.send()`
+4. Capture send timestamp (Instant + SystemTime) immediately before send call
-5. Capture send timestamp (Instant + SystemTime) immediately after send returns
+5. Call `socket.send()`
 6. Insert PendingProbe into pending map
 7. Increment sequence counters
 8. Return any events (e.g., eviction-triggered loss events from bounded map)
@@ -649,7 +649,7 @@ No signal handling in `Client`. Caller controls lifecycle by:
 - Maintains absolute send schedule: `scheduled_time(seq) = session_start + seq * interval`
 - Prepares echo request packets
 - Sends packets at scheduled times
-- Captures send timestamps immediately after send
+- Captures send timestamps immediately before send call
 - Sends compact `SentRecord { wire_seq, logical_seq, sent_at_mono, sent_at_wall }` to coordinator
 - Must NOT perform: event fanout, stats, subscriber delivery, blocking coordination
 
@@ -1861,7 +1861,7 @@ Require `irtt` server binary in PATH. Gated behind `--features interop`.
 
 **Blocks implementation:** No. This is an implementation choice.
 
-**Recommended behavior:** Capture `Instant::now()` + `SystemTime::now()` immediately after `send()` returns. This is what the spec recommends and is the simplest correct approach.
+**Recommended behavior:** Capture `Instant::now()` + `SystemTime::now()` immediately before `send()`. This ensures the measured RTT includes local send/enqueue overhead, which is more conservative for latency-control consumers like sqm-autorate-rust. The receive timestamp remains captured immediately after `recv()` returns.
 
 ### Q3: RTT When Server Processing > Raw RTT (Section 19.12)
 

docs/IRTT_CLIENT_PROTOCOL_SPEC.md

@@ -692,7 +692,8 @@ The following configuration parameters affect protocol behavior:
 
 - **Client send timestamp:** SHOULD be captured as close as possible to the
   send system call. For best RTT accuracy, the timestamp should be taken
-  immediately after the send call returns.
+  immediately before the send call, so that the measured RTT includes any
+  local send/enqueue overhead.
 - **Client receive timestamp:** SHOULD be captured as close as possible to
   the receive system call return, before any packet processing.
 - **Server timestamps:** Determined by the negotiated StampAt parameter:

docs/RUST_DESIGN.md

@@ -558,7 +558,7 @@ It should only:
 - maintain absolute send schedule
 - prepare outgoing packets before deadline where possible
 - send packets
-- timestamp successful sends immediately after send returns
+- timestamp immediately before send call
 - report compact sent records to coordinator
 
 ### Receiver Thread
@@ -845,7 +845,9 @@ The server is authoritative unless the caller explicitly requires exact or bound
 
 ## Send Timestamp
 
-Capture send timestamp immediately after `send` returns.
+Capture send timestamp immediately before the `send` call. This ensures the
+measured RTT includes local send/enqueue overhead, which is the more
+conservative direction for latency-control consumers.
 
 ## Receive Timestamp