You probably didn't understand me. I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with). That can be done for chat messages too.
You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.
By changing the recipient "end", we can arbitrarily decode the message then.
I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.
The third paragraph contradicts your other point. You define E2EE in two wildly different ways.
The chat messages are most likely stored on an intermediary server, which would qualify for the same loophole you pointed out in the cloud storage example.
Just like Netflix who purposefully scrambles the start screen to get you to watch something else rather than your favourites. They want you to not realize you have already seen all the good stuff already and unsubscribe.
You could probably configure your system monitor to show available memory - that is memory available given that cache can be dropped - rather than free memory that should always be as close to zero as possible.
Try Dolphin. Press F4 to open the terminal view. It stays in dync with the gui so if you use cd in the terminal, the contents of the new folder will be shown.
Sticky cooks