The problem with trying to add @override is that at method definition time, the decorator has no way to tell whether or not the method actually overrides another method. It doesn’t have access to the parent classes (or the current class, which doesn’t even exist yet!).
If you want to add @override, the @override decorator can’t actually do any override checking. You then have two options. Either there is no override checking, in which case @override is no better than a comment, or the type constructor needs to specifically know about @override and check it at class creation time. A convenience feature like @override really shouldn’t need to complicate core parts of the type system implementation like that. Also, if you accidentally put @override on a non-method, the bug will go undetected until you try to call the decorated function and get a weird TypeError.