fix(master): review fixes for drift restore and accept (#10)

README.md

@@ -213,7 +213,8 @@ service, in auto mode too; a person can still start one by hand. There are two w
 - **Restore desired** deploys the recorded version again (a manual job to the exact
   `repo:tag@digest`; an agent speaking protocol 3 is needed). If the service had drifted
   to another digest of the same tag, that digest is remembered, so polling does not
-  deploy it again until the registry shows a newer one.
+  deploy it again until the registry shows a newer one (unless `last_tag_digest` already
+  holds back a newer digest, which then stays).
 - **Accept running** records what runs now as the desired version. It starts no job and
   leaves the available suggestion and the update mode alone.
 
@@ -224,8 +225,10 @@ moved. **Merge** moves the old row, with its history, mode and desired version,
 location and deletes the duplicate. Merging is never automatic. It can also be done by
 hand for any removed service of the same kind (Compose or Swarm, names may differ), but
 not for plain containers, the updater itself, or a service with a queued or running job.
+A merge keeps the old row's mode and desired version, so a manually merged target with its
+own history may show drift right after the merge and can be accepted.
 
-The restore, accept and merge buttons arrive with the UI follow-up; the endpoints
+The restore, accept and merge buttons arrive with the UI follow-up (issue #28); the endpoints
 (`POST /services/{id}/restore`, `/accept`, `/merge`) and the data for them are in place.
 
 ## Adding agents