docs: health check wording follows the code (rework for #302)

The README, the comments and TODO.md say the health check gives error
only when every lookup in a round failed because no root server gave a
usable reply, and the README drops the claim that the other failures
are reported as notifications.

Model: opus-5-5

README.md

@@ -356,15 +356,15 @@ dnswatcher exposes a lightweight HTTP API for operational visibility:
 | `GET /metrics`                 | Prometheus metrics, see below |
 
 The health check, at `/.well-known/healthcheck` and `/health`, follows the most
-recent round of DNS checks. When no lookup in that round got a reply from a root
-server, because none of them answered or because the network intercepts DNS
-queries (see DNS Resolution Strategy), dnswatcher could not reach the DNS at
-all. The health check then gives `status` `error` and answers
+recent round of DNS checks. When every lookup in that round failed because no
+root server gave a usable reply, as when none of them answers or the network
+intercepts DNS queries (see DNS Resolution Strategy), dnswatcher could not reach
+the DNS at all. The health check then gives `status` `error` and answers
 `503 Service Unavailable`, so the image's health check fails and Docker and
 upaas see the container as unhealthy. Otherwise it gives `ok` and answers
-`200 OK`, as it also does before the first round finishes. A round in which the
-root servers answered gives `ok` even when a name's own nameservers do not
-answer or a domain does not exist; those are reported as notifications.
+`200 OK`, as it also does before the first round finishes. A round gives `ok`
+even when a name's own nameservers do not answer or a domain does not exist,
+since the root servers gave a usable reply to those lookups.
 
 In `/api/v1/status`, each nameserver entry and certificate entry whose `status`
 is `error` also has `error`, the reason, as in the state file (see State File