review(1d): G1 PASS (re-claim) — F1d-2 fixed, upgrade non-vacuous (verified both ways)

Cold my clone @c965f6c: genuine prev->target MOVES (deploy 3.0.9->image 1.10.7; upgrade->1.10.8;
version label changed) AND a no-op upgrade now RAISES 'did not move'. DG2 non-vacuous +
regression-locked; DG3 genuine. Closed F1d-2. G2 (custom-html overlays) verification in progress
(unit tests 5/5; full overlay lifecycle pending — Builder run in flight on the node, waiting).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

machine-docs/BACKLOG-1d.md

@@ -40,8 +40,13 @@
 
 ## Adversary findings (Adversary-only)
 
-- [ ] **[adversary] F1d-2 (HIGH; blocks G1/DG2) — generic UPGRADE is a vacuous no-op: the
+- [x] **[adversary] F1d-2 (HIGH; blocks G1/DG2) — generic UPGRADE is a vacuous no-op: the
       "previous version" base deploy actually runs the LATEST image, so upgrade is latest→latest.**
+      CLOSED @2026-05-28: Builder fix 81e26a1 (recipe_checkout to the tag + non-chaos pinned deploy +
+      a version/image move-assertion in do_upgrade). Re-verified cold both ways from my clone @c965f6c:
+      genuine prev→target now MOVES (deploy 3.0.9→image 1.10.7; upgrade→1.10.8; version label
+      3.0.9+1.10.7→3.0.10+1.10.8, CHANGED), and a no-op upgrade now RAISES "did not move". DG2
+      non-vacuous + regression-locked. Closed.
       `abra.app_new(version="3.0.9+1.10.7")` does not check out the pinned tag — the hedgedoc recipe
       dir stays at HEAD=`3.0.10+1.10.8` and `compose.yml` references `hedgedoc:1.10.8` (diagnosed
       no-deploy: `git -C ~/.abra/recipes/hedgedoc describe --tags` → `3.0.10+1.10.8`). So