Answer status on the socket instead of queuing it behind the worker

The worker runs one job at a time, and status was one of its jobs, so the
Docker healthcheck waited behind the startup scan (54 seconds of it after
the last deploy) and timed out at 5. Any scan or download longer than
three probes would have had a working daemon marked unhealthy. The socket
now answers status straight away; everything else still queues. A test
fills the queue and checks status comes back anyway.

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

docs/history.md

@@ -6,6 +6,22 @@ reasoning lives. New write-ups go at the top.
 
 See [README.md](../README.md) for what the thing is.
 
+## 2026-09-12 — Healthy while busy
+
+After a deploy the container sat at "starting" for a minute, and Docker's health log showed two
+`ipx status` probes exceeding their 5-second timeout. The daemon's own log explained it. The first
+scan after the start fetched 23 feeds, from 14:10:41 to 14:11:35, and both probes' `status`
+commands waited in the job queue behind it; they were answered together at 14:11:35, straight after
+`scan_done`. The worker runs one job at a time and `status` was one of its jobs, so any scan or
+download longer than about a minute and a half, three 30-second probes, would have had Docker call
+a working daemon unhealthy.
+
+The socket now answers `status` itself, from two short queries, and only real work goes through the
+queue. The trade is that healthy now means the daemon answers on its socket and can read its
+database; a worker stuck on one job would still pass. Asking a daemon that downloads hour-long
+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.
+
 ## 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