docs: v0.11.3 live on fmr, trains validated 120/120; two mint bugs logged

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

docs/build-status.md

@@ -1378,3 +1378,24 @@ binary is stamped with must be a pushed `server-v*` tag** — an ad-hoc stamp ab
 poisons `/releases/latest` for the string-comparing updater the moment anyone tags honestly again.
 The stale `server-v0.9.2` release (same code lineage, wrong number, created during the confusion)
 remains in Gitea but is harmless now that v0.11.3 outranks it as latest.
+
+## v0.11.3 live on fmr; trains validated end to end (2026-08-02)
+
+Deployed via `--self-update` (the pre-signing v0.11.2 updater accepted the first signed release,
+as planned; every later update verifies). Startup clean on the real host — the reserved-port
+check passed against the OS, self-test green, capabilities unchanged plus the new machinery.
+
+**`train.udp_updown` validated against production**: `LiveUpstreamTrainTest` from this PC sent
+120 packets; the server's ledger counted 120, both columnar report parts arrived, loss 0.0 %,
+`truncated=false`. The 0x03/0x04/0x05 path works, client and server, over the real internet.
+
+Two operational bugs surfaced doing it:
+- **CLI-minted tokens are lost while the daemon runs.** `devices.json` is loaded once at startup
+  and held in memory; `--mint-enroll-token` writes to disk, the running daemon never re-reads,
+  answers "unknown token", and clobbers the token on its next write. `enroll-link.sh` has only
+  ever worked by timing luck. Workaround used: mint, `systemctl restart echolot-server`, then
+  redeem. Real fix belongs server-side (re-read on miss, or route the CLI mint through the
+  running daemon).
+- **`test-fmr.sh` still mints against `127.0.0.1:8444`**, which no longer exists (the admin API
+  moved to authenticated :443). Needs the same CLI-mint flow enroll-link.sh uses — plus the
+  restart caveat above until that bug is fixed.