You can do whatever you want. No one can tell you that it is the creator of the software what you should do. Unless, of course, there is a technical reason for doing so. This is the good news. Forget good practices, this expression should be abolished from software development, this only causes wrong understanding of things.
That said, understand that these recommendations for patterns are to better organize your code. This is why you should make choices that will produce a better organization, that will make you comfortable to work in this way, allowing you to provide maintenance in a simpler way.
I have bad news. Knowing exactly what to do in each situation depends on experience. And quality, not enough quantity. The most you can do when you do not have it is to ask who you have. But keep in mind that this only works for specific cases and that nothing guarantees that the person will understand the problem. And even if you understand, it's also not guaranteed that she's committed to providing you with the best solution, even if superficially she wants it.
Answering your question here, in general, validations must be done in the template itself. This is what the "law" (: D) of MVC says.
But nothing prevents you from putting validations that you find pertinent in the controller. Some may make sense. Some may have to do with data entry itself rather than data more directly. That is, you are validating the flow.
You can not validate something in the model that depends on what you are doing to enter the data.
Some will say that it violates the MVC principle. It may be, but I do not see a better way to do it.
Of course you can do this in smarter ways, you can inject this validation externally and not code internally to the controller. You can organize the code to meet the goals of the MVC instead of following the ready formula. You can share validation code between the model and the controller. Validation should probably be a separate entity.
But you can do this when validation must also occur in the model. Some of the examples you cited would need to be validated in the model (if you just validate in the controller, someone can go over this and the model accepts data written in a disorganized way), then you can create a more modular code that can be used to validate the model and to anticipate the controller. Of course this need depends on something going a little beyond the MVC. Anyway if you're wanting to validate something on the page, you'll have to do it on JS, right? Is the template in PHP? The controller too? Did you realize that you have to do two validations that validate the same thing? There is no magic.
Note that the MVC standard tells you how the workflow should be. It does not say exactly where the code should be. The code does not need to be in one of these parts itself. Where should validation be? Anywhere. What you want to know is where it should be invoked. And you have reasons to invoke both the model and the controller, depending on the case.
As long as you do not fully understand what MVC is, why it exists, what it does to you, you can never consciously use the standard and you can not make important decisions on a case-by-case basis, / p>
We have some information here in various questions about the theme . Many are very specific and may not serve you well, others can help give you experience using experience from others. Some may have bad answers. At other times I would say that the bad ones would be badly voted, but today I can not give that guarantee.
The Wikipedia is another obvious place to start studying the subject .
A interesting article for PHP .
A worthwhile computing standards wiki .
Question in Programmers on the subject giving you various visions and ways to get more information.
Martin Fowler article with a broader view on the subject.
Reasonably detailed example .
This is just a beginning to start understanding the pattern, do not stop there. Read this ebook .