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/architecture.md

@@ -87,7 +87,8 @@ printf '{"cmd":"fetch","force":true}\n' | socat - UNIX-CONNECT:$XDG_RUNTIME_DIR/
 **Events** — `feed_start`, `feed_skip`, `feed_done`, `feed_error`, `progress`, `download_done`,
 `download_error`, `torrent_deferred`, `reaped`, `reap_done`, `scan_done`, `status`, `error`.
 `scan_done`, `reap_done` and `status` are terminal: a client that asked for work stops reading
-there.
+there. Commands run one at a time, in the order they arrive, except `status`: the socket answers it
+straight away, so the Docker healthcheck is never left waiting behind a scan or a download.
 
 Progress carries the enclosure id, without which a UI cannot tell one download from another and
 ends up animating every pending row. It is throttled to whole percents. The stream is a broadcast,