v0.238.1: the nightly backup leaves an app alone WHILE it is being updated, not only once it is held (slice 4 follow-up)

Found live in v0.238.0 Scenario F on demo-hp: during an update's 5-minute health wait the app is not
yet held, and the periodic recovery-unit capture at 10:17:09 wrote the never-started definition
(alpine:3.20) into its PRIMARY unit, 53 s before the hold landed. The Tier-2 mirror the hold names
survived only because Tier 2 runs daily; a nightly Tier 2 inside a verify window would have mirrored
the broken definition over the copy the customer is told to restore from.

backup.Manager.isHeld — consulted by the capture sweep, the Tier-2 run and the volume dump — is now
also true while a guarded update is moving the app, via SetUpdatingCheck wired in main.go to
stacks.Manager.IsUpdating. Test with positive control + red-proof; wiring pinned.

Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

controller/README.md

@@ -594,7 +594,7 @@ the boot sweep) puts a pin back or marks an interrupted update for `ResumeInterr
 
 **Every unattended start path honours a hold:** the boot sweep and the app-stop guard (as before), and
 since v0.237.0 the drive-return gate and the nightly volume dump. The nightly capture and Tier-2 run
-skip a held app so its restore point is not overwritten.
+skip a held app so its restore point is not overwritten — and, since v0.238.1, an app whose update is still in progress (the periodic capture overwrote a primary unit during a health wait, found live).
 
 **The page (v0.238.0).** `Frissítés` follows the job — the button shows the phase label and the page
 reloads when the update ends. An updating card offers no lifecycle button; a held card shows the hold