R-717: after_setup open_command — the family window reopens an app's DB-held sign-up switch

The command form ran only when the lock was SET, so a database switch closed by
`command` stayed closed through the household's 15-minute window. New twin
fields `open_command` + `open_success` (same service/user/args_env and the same
argv-safe expansion and success-marker rules as `command`/`success`).

- liftNativeLock (the window, via OpenSignupWindow → goNativeLock(false)): marks
  the gate record native_lock "opening" BEFORE anything opens, lifts the env,
  runs open_command; only full success records "lifted". A failed open closes
  the switch again at once and records after_setup {ok: false, step: open}; the
  app page shows its own line (app_info.signup_native_open_failed).
- The close: reconcileSignupBlocks (every 20 s and at controller start) runs
  `command` for any non-"applied" state once no window runs. A failed close
  after a window is logged ERROR ("may still be OPEN past the household's
  window") and retried every nativeLockOpenRetry (2 min) instead of 30.
- After a successful app update, verifyAndConclude → markNativeLockForReapply
  sets native_lock "" so the loop closes the switch again.
- A template with `command` but no `open_command` keeps today's window (env
  only) and logs once per app that its own switch cannot be reopened.

Tests: internal/stacks/after_setup_r717_test.go (7), web render + parity case.

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

controller/internal/stacks/update.go

@@ -1031,6 +1031,7 @@ func (m *Manager) verifyAndConclude(ctx context.Context, name, dir string, env [
 	m.clearFailedStep(name, dir)         // R-680: and the failed-step record
 	m.clearJournal(name)
 	m.removePreUpdateCopies(dir)
+	m.markNativeLockForReapply(name, dir) // R-717: the loop closes the app's own sign-up switch again after an update
 	// R-678 (v0.271.0): the app's catalog fields — ladder_steps_left, the badge's inputs, the pin — are
 	// re-read NOW, before Updating goes false, so neither a person nor the automatic leg ever reads the
 	// pre-update values after `done`. MEASURED 2026-09-24: ~50 s stale, six re-presses by the caller.