Feature request: integrate with Android Telecom (ConnectionService) for native call handling

Is your feature request related to a problem? Please describe.
Talk's incoming-call UI (CallNotificationActivity) is entirely custom-drawn by the app, outside Android's Telecom framework. A code search of this repo turns up zero references to ConnectionService or TelecomManager anywhere in talk-android. By contrast, apps like Signal, WhatsApp, and Google Meet register as a self-managed ConnectionService/PhoneAccount, which gets them guaranteed native incoming-call UI independent of the app's own full-screen-intent/notification-channel setup, correct interaction with Do Not Disturb "allow calls from" exceptions (a custom channel's bypassDnd flag is easy to get wrong or have silently reset), and native call-log entry plus Bluetooth/car head-unit integration shared with the rest of the OS.

I ran into this while debugging intermittent missed Talk calls on a GrapheneOS phone. Full-screen intent permission, battery optimization, Doze whitelisting, and notification channel importance were all already correctly configured, and the app rang reliably in every test I could run, including a forced deep-Doze test, so the custom call UI is mostly fine but has less of a safety net than Telecom integration would provide for edge cases I couldn't reproduce on demand.

Describe the solution you'd like
Adopt Android's self-managed ConnectionService API (PhoneAccount plus ConnectionService) for Talk calls, the same approach Signal uses, so incoming/outgoing Talk calls are treated as first-class calls by the OS instead of a custom notification-driven UI.

Describe alternatives you've considered
Continuing to tune the current custom call-notification path (full-screen intent, notification channel importance, battery whitelisting). This works when correctly configured, but is more fragile than OS-level Telecom integration and easier to silently break via unrelated OS/app updates or user settings changes.

Additional context
Happy to help test on GrapheneOS if this is picked up.

Start with the existing CallNotificationActivity and the incoming/outgoing call flow, then confirm the Android manifest and call-handling entry points involved. Compare the current notification-driven path with the requested self-managed PhoneAccount and ConnectionService integration; done means Talk calls are handled through Android Telecom with native call UI, call-log support, and Bluetooth or car integration.