engine: split packet loss by direction using the server's observations

"3 % loss" sends an engineer looking in both directions at once. The server
records every packet it received per sequence number, so the two cases are
distinguishable: sent-but-never-seen is upstream loss, seen-but-no-reply is
downstream. The findings say which, and say what is not implicated.

Downstream loss is measured against what reached the server, not against what
was sent — the other denominator counts every upstream loss twice and
overstates the return path.

Per-direction jitter comes out of the same records without needing synchronised
clocks: (server_rx - client_tx) carries a constant unknown offset, and
differencing successive samples cancels it, so RFC 3393 variation is honestly
attributable to a direction even though absolute latency is not.

Correlation is by wire sequence number, not loop index — the counter is shared
with every packet type on the session. ProbeSession exposes it even for a lost
probe, since that is precisely the packet whose direction is in question.

Live against fmr: 0.08 ms upstream jitter vs 0.85 ms downstream, an asymmetry a
round-trip test cannot see.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/build-status.md

@@ -694,3 +694,37 @@ Two process notes from this round:
   token. Caught by deploying and *looking at the response*, not by trusting a green build.
 - The live suite is now six tests (`LiveServerTest`, `LiveMeasurement`, `LiveGranted`,
   `LiveUpload`, `LiveCompat`, `LiveEnrollment`), all green against fmr from the PC with no device.
+
+### Directional loss: which way is the packet loss? (2026-08-01)
+A round trip can only report that *something* was lost somewhere, which is the least useful form
+of the answer — "3 % loss" sends an engineer looking in both directions at once. The server
+already records every packet it received per sequence number (§6), so the two cases are actually
+distinguishable, and `train.udp_updown` now reports them separately:
+
+- sent, never seen by the server → **upstream** loss
+- seen by the server, reply never arrived → **downstream** loss
+
+Findings name the direction and say what is *not* implicated, which is half the value:
+`connectivity.loss_upstream` ("the return path is not implicated: replies came back for everything
+that arrived"), `connectivity.loss_downstream`, `nat.udp_unreachable_upstream`.
+
+Two things the implementation gets deliberately right:
+- **Downstream loss is measured against what reached the server**, not against what was sent.
+  Using "sent" as the denominator counts every upstream loss a second time and overstates the
+  return path. Pinned by a test with loss in both directions at once.
+- **Per-direction jitter without synchronised clocks.** Absolute one-way delay would need clock
+  sync and we deliberately have none (the two-clock rule). But `server_rx − client_tx` carries a
+  constant unknown offset, and differencing successive samples cancels it — so RFC 3393 one-way
+  delay variation *is* honestly attributable to a direction even though latency is not. A test
+  pins that a 10-second clock offset changes nothing.
+
+Correlation is by **wire sequence number**, which is not the loop index: the counter is shared
+with every other packet type on the session, so "the nth echo" is not "sequence n". `ProbeSession`
+now exposes `lastSeq`, including for a probe that was lost — a lost packet still has a sequence
+number, and that number is exactly what tells you which way it was lost.
+
+Live against fmr: 20/20 both ways, and jitter of **0.08 ms upstream vs 0.85 ms downstream** — a
+tenfold asymmetry that a round-trip measurement cannot see at all.
+
+10 unit tests on the arithmetic (a wrong denominator here does not crash, it produces a plausible
+number pointing at the wrong half of the network) plus the live correlation check.