Is the relationship between a View and a Controller in MVC really just a Strategy pattern?

The Gang of Four book states the following:

[...] The main relationships in MVC are given by the Observer, Composite and Strategy design patterns.

The best example of this I could find was this github repo, which shows the following class diagram:

I'm particularly interested in the Strategy part of the MVC, where the following holds:

MVC Name	GoF Name
View	Context
Controller	Strategy
ConcreteController	ConcreteStrategy

Regarding the relationship between View and Controller, The book Head First Design Patterns states the following:

The controller may also ask the view to change. When the controller receives an action from the view, it may need to tell the view to change as a result. For example, the controller could enable or disable certain buttons or menu items in the interface

It also shows an example where the ConcreteController equivalent BeatController) defines an additional association with the ConcreteView equivalent (DJView):

package headfirst.designpatterns.combined.djview;
  
public class BeatController implements ControllerInterface {
    BeatModelInterface model;
    DJView view;
   
    // BeatController implementation
}

This association is not present in the Strategy pattern, which only has an arrow going from Context to Strategy (and not the other way round).

I've seen many other examples online where such an association from the Controller to the View is defined. Is the relationship between Controller and View really only a strategy? If not what is it?