Fix Google Messages RCS setup support

[BeauDevCode]

Fixes #2994.

This PR improves microG compatibility with Google Messages RCS setup by implementing the missing service/permission/config behavior needed for RCS initialization without requiring root, Magisk, or bootloader unlock.

Summary:

• Adds the Constellation service surface used by Google Messages for phone-number verification, including IID token registration, Jibe/Google Constellation RPC flows, TS.43/EAP-AKA handling, SMS/silent verification challenge processing, and capability reporting.
• Adds the Asterism consent service surface used during RCS provisioning and returns the consent/IID data Messages expects.
• Adds the RCS service routing, stock-parity caller allowlist checks, and per-call binder caller validation for the internal RCS provisioning APIs.
• Exposes RCS Phenotype/config flags for Google Messages and the IMS library so the UPI/Jibe provisioning path is enabled and attestation gates are not incorrectly required.
• Adds the required telephony/SMS permissions and updates supporting DroidGuard/AppCert/ProviderInstaller behavior used by the registration path.
• Adds focused unit coverage for Constellation behavior, TS.43 parsing/crypto, and RCS caller policy checks.

Attribution:

This branch is based on the active Constellation/Asterism RCS implementation line in #3388, plus the caller/capability hardening from #3495, with the unrelated CI artifact workflow tweak intentionally omitted.

Testing:

• ./gradlew.bat --no-daemon :play-services-core:testVtmDefaultDebugUnitTest --tests org.microg.gms.constellation.ConstellationServiceImplTest --tests org.microg.gms.rcs.RcsCallerPolicyTest --tests org.microg.gms.constellation.Ts43ClientTest
• ./gradlew.bat --no-daemon :play-services-core:assembleVtmDefaultDebug

Both commands passed locally using Java 17 and Android SDK platform 35/build-tools 34.0.0.

Device/emulator testing was not performed in this environment. No Google Messages version was tested locally. Maintainer/device validation is still needed across locked-bootloader devices, carriers, and recent Google Messages builds.

[BeauDevCode]

Follow-up update:

• Merged current upstream master into this PR branch and resolved the remaining conflict in play-services-core/src/main/kotlin/org/microg/gms/phenotype/PhenotypeService.kt.
• The resolution preserves this PR's RCS provisioning phenotype flags and upstream's newer Translate/NotebookLM/Google Messages Penpal phenotype flags. The duplicate com.google.android.apps.messaging#com.google.android.apps.messaging entry now uses a combined GOOGLE_MESSAGES_FLAGS array.
• git diff --check passed.
• I attempted the targeted unit test command with a portable Java 17 runtime, but local execution is blocked because this machine does not have an Android SDK configured (SDK location not found; no ANDROID_HOME/sdk.dir).

No runtime behavior beyond the phenotype flag merge was intentionally changed in the conflict resolution.

[capturartelab]

I reviewed the Constellation request handling in this PR and found a small correctness issue worth folding in before more device testing.

VerifyPhoneNumberRequest.policyId is documented in this branch as the UPI policy string, not the phone number:

// field 1: policyId - UPI policy string (e.g., "upi-carrier-id-mt-priority"), NOT phone number
// field 5: imsiRequests - List of IMSI/MSISDN pairs per SIM

ImsiRequest.msisdn is documented as the E.164 phone number:

// msisdn: MSISDN/phone number (E.164 string)

The current verifyPhoneNumber() implementation initializes phoneNumber from request.policyId, so a non-phone policy string can be passed into the TS.43 entitlement flow. I prepared a small patch that:

• prefers a valid E.164 imsiRequests[].msisdn,
• preserves the legacy V1 bundle path where the phone number is adapted through policyId,
• avoids sending a non-phone policy ID as the entitlement phone number,
• adds focused regression tests for MSISDN extraction, non-phone policy IDs, and the legacy V1 compatibility path.

Patch summary:

+    static String extractMsisdnFromRequest(VerifyPhoneNumberRequest request) {
+        if (request == null) return null;
+        if (request.imsiRequests != null) {
+            for (ImsiRequest imsiRequest : request.imsiRequests) {
+                if (imsiRequest != null && isE164PhoneNumber(imsiRequest.msisdn)) {
+                    return imsiRequest.msisdn;
+                }
+            }
+        }
+        // Legacy bundle callers are adapted through policyId in verifyPhoneNumberV1().
+        return isE164PhoneNumber(request.policyId) ? request.policyId : null;
+    }
+
+    private static boolean isE164PhoneNumber(String value) {
+        return value != null && value.startsWith("+") && value.length() > 1;
+    }

and:

-            String phoneNumber = request != null ? request.policyId : null;
+            String phoneNumber = extractMsisdnFromRequest(request);

Local validation note: git diff --check passes for the two touched files. I attempted the targeted Gradle test command:

:play-services-core:testVtmDefaultDebugUnitTest --tests org.microg.gms.constellation.ConstellationServiceImplTest --tests org.microg.gms.rcs.RcsCallerPolicyTest

but the Windows sandbox fails before reaching play-services-core tests while Java resolves android.jar:

java.nio.file.AccessDeniedException: ...\android-sdk\platforms\android-35\android.jar

I isolated that as an environment issue: Java Path.toRealPath() fails in this sandbox even for a plain local file, while PowerShell/.NET can read the same files.