Usually, each message is encrypted with a new symmetric key that's unique per message and that key is encrypted with the public key of the recipient and include

Usually, each message is encrypted with a new symmetric key that's unique per message and that key is encrypted with the public key of the recipient and included in the envelope of the message. It isn't hard to ask the client to also encrypt the symmetric key to company's own monitoring public keys and include it in the envelope. Presumably this can be done dynamically on-demand (when a govt monitoring request comes in) by the company servers. It is also conceivable that all symmetric keys of past 30 days of messages are stored on the client and can be asked to be sent to server on-demand. If all this functionality ("backdoor") is already baked into the client, and carefully masked to look like legitimate functionality of the app, then there's no need to "compromise" the client afterwards. We are talking about private, for-profit companies running closed-source service with closed-source client and with TLS-key-pinned client-server RPCs. And we are talking about closed-source phones running closed-source hardware, firmware, OS, and platform services. Even if the app was open-source (like Signal) there are plenty of injection points to do the above at the lower-levels.