app: speak train (0x03-0x05) and mark downtrains with DSCP

ProbeSession sends paced upstream trains and fetches the server's columnar
received view; UpstreamTrainMeasurement lines both ledgers up per sequence
number into TrainEvidence - the directional loss attribution a round trip
cannot make. Loss is computed against the server's total count, not its
row list, so a buffer-capped report can never invent loss on big trains.
A missing report stays ambiguous by name (report lost, or server predates
trains) instead of being blamed on the train.

downtrain actions can now request a DSCP marking, recording dscp_applied
so a survival comparison never blames the path for a marking the sender
skipped.

Also logged: fmr runs v0.11.2 built from commits this repo's remote never
saw, so --self-update on fmr is OFF-LIMITS until that lineage is repaired
- the fresh server-v0.9.2 release is newest-created but semantically
older, and the updater compares strings, not SemVer.

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

docs/build-status.md

@@ -1346,3 +1346,24 @@ The spec-vs-implementation gap audit closed its top items; protocol_version 1.0.
 
 Client-side counterparts still to build: sending 0x03 trains + parsing 0x05 reports
 (`train.udp_updown`), and passing `dscp` on downtrain actions.
+
+## ⚠ Version lineage broken: fmr runs v0.11.2, the repo's tags stop at v0.9.x (2026-08-02)
+
+Discovered while preparing to self-update fmr to the freshly released server-v0.9.2:
+**fmr runs v0.11.2** (binary installed 2026-08-02 08:51), but this repo's remote has tags only
+up to `server-v0.9.1`, master fast-forwarded cleanly from this machine, there is no v0.10/v0.11
+release in Gitea, no source checkout or Go toolchain on fmr, and no deploy script in this repo
+that stamps versions. Conclusion: v0.11.2 was cross-built from a clone whose commits were never
+pushed — presumably another dev machine.
+
+Consequences until resolved:
+- **Do NOT run `--self-update` on fmr.** Gitea's `/releases/latest` is the *newest-created*
+  release, which is now `server-v0.9.2` — semantically older than the deployed binary; the
+  updater compares strings, not SemVer, and would happily "update" v0.11.2 down to it. No
+  automatic risk exists (fmr has no update timer installed, only the cert timer), but a manual
+  run would downgrade.
+- The next real release must be tagged **above v0.11.2** (e.g. `server-v0.11.3` or `v0.12.0`)
+  *after* the missing commits are pushed, so "latest" becomes truly latest again.
+- The unpushed v0.10–v0.11 work needs to be found and pushed from whichever machine built it,
+  or the deployed binary's provenance re-established some other way, before the release channel
+  can be trusted again.