Your proposed solution is an insecure system that can and almost certainly will be hacked. That’s the point. You could make insecure encryption pretty easily. What you can’t do is make something that is secure and yet also has a key that gets handed out all over the place. In the last decade alone, there have been all sorts of examples of exactly these kind of security keys being leaked.
There is no key that gets handed out all over the place. Numerous people are trying to explain that on this thread. Even a purely textbook cryptography setup would involve the private keys being generated inside an HSM and never leaving it. Only the public key would be widely distributed. A public key lets you encrypt a message but not decrypt it.
The hard part here isn't key leaks. System critical keys are commonplace in our society and virtually never leak, exactly because they don't tend to leave dedicated hardware. For example e-Passports are signed with long term government keys, they don't leak all the time. The US DoD runs a large scale private PKI, no problem. Our society has even got pretty good at physically giving people private keys in such a way that they still can't access them: credit cards, SIM cards, games consoles. The hard part is the workflows around them. Ensuring the HSM only decrypts messages for authorized users and things.
Even if you assume HSMs are constantly getting ransacked, governments don't care. They don't even necessarily want to have their own key management to deal with at all. A web portal that employees log in to, type in a phone number and then see the logs is perfect for them. Make it be dedicated hardware supplied by Facebook itself if you want, with login systems as secure as they use for their own employees. Governments just do not care about these details. Type 1 Nos, to use your lingo.
The hard part of such a system is defining your precise security goals and then implementing it in ways that all the goals are met simultaneously. So called "E2E encryption" isn't really, we all know that, so there's lots of flex to define systems that meet the same goals in different ways especially if you're willing to roll with good-enough type solutions e.g. assume a trusted client (which e2e messengers do already for things like their forwarding counters).
