fix(master): seed the tag digest from running services and hide registry error text (#9)

README.md

@@ -132,8 +132,9 @@ multi-arch image the digest is the index digest, the same one `docker inspect` s
   already suggested is not suggested again. A service in **auto** mode also gets an update
   job to `repo:tag` (the agent resolves the digest itself, so agents on protocol version 2
   keep working). The master remembers the newest digest it started or deployed for the tag
-  in `services.last_tag_digest` (set when polling starts a job and when any plain tag job
-  succeeds, whoever started it) and starts no job for that digest again, whether the job
+  in `services.last_tag_digest` (set when polling starts a job, when polling sees the
+  service already running that digest, and when any plain tag job succeeds, whoever started
+  it) and starts no job for that digest again, whether the job
   failed or the user rolled back afterwards. If the service already had a job when the
   digest was found, the next cycle tries again.
 - **What is not polled.** Services that follow no tag (`repo@digest`), `build:` services, and
@@ -154,7 +155,9 @@ multi-arch image the digest is the index digest, the same one `docker inspect` s
   registry host in the image name, including a `GET /v2/` ping that follows redirects.
   Anyone who can start containers on a managed host can therefore make the master send
   blind requests to internal hosts. The registry's answer is not shown: an error keeps only
-  the HTTP status and the registry's error codes.
+  the HTTP status and the registry's error codes; any other failure shows only "timeout",
+  "cannot reach registry" or "lookup failed". The full error goes to the master's log
+  (`registry_lookup_failed`).
 
 ### Version history and rollback
 
@@ -174,6 +177,9 @@ digest-pinned or tagless versions need an agent speaking protocol version 3 (thi
 release); on an older agent the job fails with "agent too old to deploy a pinned version
 (needs protocol 3)".
 
+A rollback made before the first poll cycle after the upgrade has seen the service is not
+protected, because the master has not yet recorded the digest it was running.
+
 A service in **auto** mode stays auto after a rollback. Polling does not undo it: the
 service stays on the older version until the registry shows a digest of the followed tag
 that differs from the newest one the master deployed. The newer version it was rolled back