docs: record that a revived beacon belongs in the web UI, not its own listener

Its Python service wildcard-bound 0.0.0.0:443, which is what silently
compromised the reserved measurement address. Two routes on the admin UI
would inherit the TLS and certificate already in place, need no extra
port, and pick up authentication the standalone receiver never had.

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

docs/build-status.md

@@ -1163,3 +1163,20 @@ the very name the certificate is issued to. sshd likewise now listens on `.150`,
 The point of all this: `fmr.echo-lot.app` gains an A record, so the server stops being reachable
 only over IPv6 — which is what made it unreachable from a phone with no working IPv6, presenting as
 "this host does not exist" in two different browsers.
+
+### If the beacon comes back, it belongs in the web UI
+
+Not as a separate listener. The receiver being its own Python service on `0.0.0.0:443` is exactly
+what silently compromised the reserved address, and a second process racing for a port is a
+recurring problem rather than a one-off: whoever loses the race simply fails to start, and on a
+reboot which one that is comes down to unit ordering.
+
+Folding it in costs little and settles several things at once. It would be two routes on the admin
+UI (`POST` the observed adb port, `GET /apk` for the staged build), behind the TLS the UI already
+terminates and the certificate it already renews, with no extra port and no wildcard. It also gets
+authentication for free — the current receiver accepts a port report from anyone who can reach it,
+which is tolerable for a dev tool on a trusted network and not something to keep once it lives
+beside an admin session.
+
+The one thing that changes on the device side is that the POST becomes HTTPS. That is a real
+certificate rather than a self-signed one, so it costs a URL scheme rather than any trust plumbing.