Answer status to the client that asked, not everyone

status is a terminal event. Broadcast, the healthcheck's answer ended any
ipx fetch that was watching a scan, which stopped reading at the next probe
while the scan carried on. It could not happen while status waited behind
the scan; answering it at once made it happen every 30 seconds. Each
connection's writer now takes private replies beside the broadcast, and
the test checks another client hears nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TAC7sLVqfKmY6rsTLXzNgk

docs/history.md

@@ -22,6 +22,13 @@ database; a worker stuck on one job would still pass. Asking a daemon that downl
 podcasts to be idle within five seconds was never a fair test of whether it was alive. A test holds
 the queue full and checks `status` still comes back.
 
+The first version broadcast the answer, as the queued one had been. Timing `status` during a forced
+scan in production showed the catch: `status` is a terminal event, so the `ipx fetch` watching that
+scan stopped reading at the first probe and printed the status line as its last, while the scan
+carried on. When `status` waited behind the scan it could never arrive first, so this had never
+shown. The answer now goes only to the client that asked, and the test checks that another client
+hears nothing.
+
 ## 2026-09-12 — Signing in through Authentik, for real
 
 Ray could not get Authentik's sign-in to reach ipx, following `docs/sso.md`, which had been written