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

CLAUDE.md

@@ -143,7 +143,6 @@ DATABASE_URL=postgres://... go test -tags integration ./internal/master/store/
   newer suggestion, and a digest-pinned pick does not clear a digest-less (webhook) one.
 - **Job output is capped at `protocol.MaxJobOutput` (128 KiB, tail).** NUL bytes are
   stripped by the hub because Postgres text rejects them.
-
 - **Drift compares by digest, not by string** (`model.RunsRef`): `repo:tag@D` is run by
   `repo:tag` reporting digest D. Same digest under another tag is not drift. Different
   repo strings (`nginx` vs `docker.io/library/nginx`) are.
@@ -151,9 +150,15 @@ DATABASE_URL=postgres://... go test -tags integration ./internal/master/store/
   inventory write for the row; `Service.Drifted()` is false meanwhile, since `desired_ref`
   is ahead of `actual_ref` for a debounce interval after every job.
 - **Accept never touches `last_tag_digest`, `available_*` or `update_mode`**, and the
-  `actual` form field is only a guard against a changed service; the value written comes
-  from the row. `RestoreDesired` sets `last_tag_digest` to the drifted digest when it is
-  another digest of the desired tag.
+  `actual` form field (`Service.RunningRef()`, ref plus digest) is only a guard against a
+  changed service; the value written comes from the row. `RestoreDesired` sets
+  `last_tag_digest` to the drifted digest when it is another digest of the desired tag and
+  `last_tag_digest` is empty or equals the desired digest (otherwise it holds back a newer
+  digest and stays).
+- **`awaiting_inventory` can hide real drift** until the next inventory change when a job
+  result arrives after the snapshot that shows the drift (an agent reconnect resends its
+  outbox after the snapshot), or when Swarm coalesces an update and a rollback into one
+  debounce interval. This is accepted.
 - **Merge lock order is agent, then service rows by id** (as in inventory writes), and the
   duplicate row is deleted before the old row is updated, because `location_key` is unique
   and not deferrable. A removal racing a merge can be lost; the next snapshot fixes it.