v0.263.0: a failed update puts the app back by itself (09 decision 15, R-637)

The guarded update gains a folder copy of the app's named volumes, taken
after the pull where the app stops anyway (decision 19, chosen by the
2026-09-23 bake-off). On a failed health check the box undoes: every copy
validated by its finished-marker first, volumes refilled, definition and pin
from the job's own pre-update copies, the old version checked with the OLD
.felhom.yml probe. It holds only if the undo fails, and the hold sentence
says so and what state the data is in. Bind-mounted folders are never
touched.

- R-637 built; R-638/R-640/R-641 do not arise with a folder copy; R-639
  (pre-update copies incl. .felhom.yml kept until the undo is over).
- journal phases copying/undoing with power-cut recovery.
- app.yaml last_update_undone + one line on the app page (hu/en).
- R-642: start/restart never answer "completed".
- Removal deletes kept undo copies.

MinAgent unchanged (0.131.0). Nine red-proofs in REPORT.md.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

controller/internal/stacks/deploy.go

@@ -154,6 +154,10 @@ type AppConfig struct {
 	// ABSENT MEANS UNPINNED, and unpinned means the app behaves exactly as it did before
 	// v0.235.0. It never means "pin to whatever the catalog says now".
 	PinnedImages map[string]string `yaml:"pinned_images,omitempty" json:"pinned_images,omitempty"`
+	// LastUpdateUndone (v0.263.0, 09 §3 decision 15) is the last update the box UNDID by itself —
+	// written only by a successful undo, cleared by the next successful update. The page shows one
+	// line from it; the future automatic caller reads it so it never re-presses the same step.
+	LastUpdateUndone *UpdateUndone `yaml:"last_update_undone,omitempty" json:"last_update_undone,omitempty"`
 }
 
 // InstalledImage is one compose service's observed image. See AppConfig.InstalledImages.