I sympathize. My son is in the seventh grade. Half the "wrong" answers he loses credit for on his assignments are, in my opinion, the result of ambiguous questions that could fairly be answered more than one way.
However, I believe this sentence is unambiguous:
The controller will create an instance of CounterModel with the initial value and call increment until the end value is reached.
This says that the controller will do two things: 1) it will create an instance of CounterModel with the initial value; and 2) it will call increment until the end value is reached. Thus, I think Line 18 of your CounterModel source code puts the call to increment in the wrong place. It should be in the controller.
The wording of your assignment is silent on the question of where the view should be created. There are a variety of options people use, but I am pretty sure the model is
not where the view should be created. You can do any of these: 1) CounterTest.main can create the view, and pass it a reference to the controller (this is an implementation of the strategy
pattern, and is the one I personally like best); 2) CounterTest.Main can create the view, which, in turn, can create the controller itself (this hard-codes your choice of controller within the view code, which is what the strategy pattern lets you avoid doing, but I've seen a lot of example MVC programs do it this way); or 3) CounterController's constructor can create the view and pass it a reference to itself (that is, the controller can pass
this to the view's constructor, which may or may not get you a warning about dubious parameters in constructors, depending on your
IDE and/or any other source of helpful advice you have).
There are other ways, as well, to get the model, view, and controller created and able to communicate, but I very much doubt that having the model create the view is a popular choice. That makes the model dependent upon the view, when one of the great virtues of MVC is supposed to be that the view can change at any time (even at run-time), with no accommodation required of the model to do so. Indeed, you can even have multiple views instantiated at the same time and, again, the model need not provide any support, other than emitting events. By structuring your code this way, you could, for example, replace the view you've got with one that moved a needle on a graphic timer, or blinked some number of lights. As you have written it, however, at a minimum, you would need to
rewrite CounterView to make those changes, since your model has a hard-coded reference to CounterView's constructor. If you defined an interface for your view, your model could use that to send events, and you could change your view from CounterView to some other class that implemented the same interface, but
only if you create the view somewhere
other than inside the model (and then pass the model a reference to the view, with the reference being of the interface's type).
So, those are my suggestions (since the big boys haven't arrived yet). Move the call to increment out of the model and into the controller, and create the view outside the model.