It is both of those if you use a typechecker, which is the whole reason it exists (in fact, the first popular typechecker existed before the annotation syntax using type comments; type annotations were developed specifically so that it could be accommodated in the language rather than becoming its own separate language.)
That's the problem! The code should not run if the types are wrong. Having an external tool is an antipattern.
Having to rely on process for validity is a recipe for bad. We already know how the greater python community has been with requirements.txt and dependencies. I've spent days fixing this garbage.
It's a tooling problem. Good tools make good habits part of the automation and stop you from having to think about it.
It's not checked, it's not required, and the bolted on syntax is ugly.
Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised.
We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.