Fix Shelly unreachable: roll back engine state on failed actions

Without this, a failed Execute() left engine state diverged from hardware.
SyncHardwareState would then misread the mismatch as a manual override and
apply a 1-hour lockout — causing either a stuck-on or stuck-off loop.

Now Execute() returns per-action []error. The control loop calls
Engine.RollbackAction() for each failed action, keeping engine state in
sync with hardware so the next cycle simply retries.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

internal/actuator/actuator.go

@@ -38,26 +38,30 @@ func NewActuator(cfg *config.Config, vc *viessmann.Client, logger *slog.Logger)
 	}
 }
 
-// Execute performs a list of switching actions.
-func (a *Actuator) Execute(ctx context.Context, actions []engine.Action) error {
-	for _, action := range actions {
+// Execute performs a list of switching actions and returns one error per action
+// (nil on success). Failed actions do not prevent subsequent actions from running.
+// The caller should roll back engine state for any failed action using
+// Engine.RollbackAction so that the next SyncHardwareState cycle does not mistake
+// the divergence for a manual override.
+func (a *Actuator) Execute(ctx context.Context, actions []engine.Action) []error {
+	errs := make([]error, len(actions))
+	for i, action := range actions {
 		if err := a.executeOne(ctx, action); err != nil {
 			a.logger.Error("action failed",
 				"consumer", action.Consumer,
 				"turn_on", action.TurnOn,
 				"error", err,
 			)
-			// Continue with other actions even if one fails
+			errs[i] = err
 			continue
 		}
-
 		a.logger.Info("action executed",
 			"consumer", action.Consumer,
 			"turn_on", action.TurnOn,
 			"reason", action.Reason,
 		)
 	}
-	return nil
+	return errs
 }
 
 func (a *Actuator) executeOne(ctx context.Context, action engine.Action) error {