All the device knows is that it trusts some root CAs and not others. You add your personal root CA to the trusted list; so it's trusted.

Unless the site uses some kind of certificate pinning (c.f. HPKP), one trusted root is as good as another.

This is how TLS inspection is done on corporate networks. IT will apply a group policy that puts a company-owned root certificate into the trusted roots on your Windows machine - maybe the same one that's used for the rest of your internal PKI.

You then issue a subordinate CA from that root, and your web proxy infrastructure (Bluecoat or whatever) then uses that CA to do just-in-time provisioning of certs for whatever domains you're intercepting.

The phone doesn’t, as the sibling comment mentions, but the app might (if it’s doing certificate pinning).

No, I believe you would have to recompile the app with your cert or use Frida or something to hook the cert check function.

I'm not sure how Apple's ecosystem or web frameworks limit the validation on a backend, which is pretty much platform agnostic. The limitations are bound by what a HTTP response can provide, and the error states the front-end devs are willing to handle. During my time as a mobile/web dev, the back-end devs were always compliant with providing the error information where relevant, and would enforce business requirements (e.g., paid users are only authorized to do 'x') on the back-end. Once again, it's more expedient to not care, but I think Bumble has the budget and self-interest to care for the examples in the article.