The owner of the domain has to choose to integrate a CDN. They implicitly trust the vendor who runs the CDN just like they implicitly trust the cloud provider that asserts their VPC between their server that terminates TLS and any API servers behind that which don’t use encryption for data in transit.
3rd party could mean a DBA, IT consultant, AWS support tech, CDN support tech, MSSP employee, cloud platform, etc. those all come with different levels of risk, different contract terms, etc.
I’m trying to say that just saying the TLS connection is terminated by a vendor, who then creates another to the origin server doesn’t tell you anything valuable from a security / risk standpoint. The CDN-fronted connection that shows the warning may be highly secure while a self-managed reverse proxy that terminates the TLS connection to another serve owned+managed by the same person/org might be completely insecure. The warning is not a useful signal.
If it turned out "End to end" encrypted chat went through a third party that even transiently had access to the plaintext version of the chat (like how Cloudflare works) you'd be apoplectic.