I just posted https://peps.python.org/pep-0800/, which proposes adding an @solid_base decorator to the type system. "Solid bases" are classes that don't allow inheritance from other solid bases, which includes most builtins.

Usually our policy is not to use draft PEPs in typeshed until they are accepted. I think in this case, it's worth making an exception:

• Even if type checkers don't support the decorator, they'll still be able to use the stubs with no regression in functionality. They'll just see an identity decorator on some classes. I tried this just now in Add @typing_extensions.solid_base #14443 and CI shows that mypy and pyright are unaffected by the presence of the decorator on int and str. (There are some other CI failures for unrelated reasons.)
• While type checkers could implement the feature before typeshed adds @solid_base decorators, the feature will be a lot more useful if standard library classes are correctly marked with the decorator.

If we're in agreement, I would propose to start adding the decorator in typeshed once there is a typing_extensions release with the new feature. I can then also add stubtest support for checking whether the decorator should be present.