Constellation: reuse cached verification state for RCS

[paulcakeface]

Summary

Adds a focused cached-verification path to the current microg#3808 Constellation VerifyPhoneNumber flow.

When Google Messages requests RCS verification and microG already has persisted Constellation verification state, the flow now:

• keeps RCS: consolidated Constellation/Asterism hardening for #2994 microg/GmsCore#3808's fail-closed RCS consent check first
• performs one read-only GetVerifiedPhoneNumbers request before Sync/PNV
• requires an exact target-number match when a phone hint is available
• requires a non-empty server-issued id_token
• returns that token as PhoneNumberVerification.verificationToken
• preserves the resolved SIM slot in the returned verification

If no cached verification state is available, the existing Sync/PNV path is unchanged. A GPNV error is surfaced rather than used as permission to start another PNV attempt.

Why

Current Google Messages consumes the GPNV id_token synchronously as its MSISDN bootstrap token. When Constellation already has verified state, re-running Sync/PNV first is unnecessary and can consume another verification attempt.

Validation

This branch is based directly on the current microg#3808 head:

223f91fe0cde7be17bcd19bb0e28087526d98bc4

Offline validation:

• git diff --check: PASS
• focused CachedGpnvFastPathTest: PASS
• existing VerificationConsentGateTest: PASS
• full :play-services-constellation-core:testReleaseUnitTest: PASS
• full :play-services-core:assembleMapboxDefaultRelease: PASS
• final full build: 3,429 actionable tasks, BUILD SUCCESSFUL

Locked/no-root physical validation

The exact PR-derived code was built as a signed update-in-place test APK and exercised on a physical Pixel 3 with:

• bootloader locked
• Verified Boot green
• production user / release-keys build
• ro.secure=1, ro.debuggable=0
• no su in the shell path/common system locations
• no Magisk, KernelSU or APatch package/mount markers
• Google Messages messages.android_20260827_01_RC02.phone_dynamic

The exact candidate installed with byte-for-byte APK readback. One controlled RCS OFF -> ON treatment then entered the new cached-GPNV path on that locked/no-root device.

The live GPNV request returned RESOURCE_EXHAUSTED from Google's Phone Number Verification service before a JWT was returned. No Sync/PNV fallback was observed. I stopped after that single result rather than retrying the known quota boundary.

So this exact rebased branch is physically proven to execute on locked/no-root hardware, but this run does not claim a fresh successful JWT handoff or complete microg#2994 acceptance.

Prior positive evidence for the same cached-GPNV behaviour

An earlier equivalent implementation on a locked/green Pixel 3 completed the positive path: one exact-target GPNV response returned a genuine JWT, no Sync/PNV ran, and Google Messages consumed it as a non-empty MSISDN token (msisdnToken length: 948). Provisioning then moved downstream to RequestWithMsisdnTokenState, where that separate request returned HTTP 400.

Scope and provenance

This is intentionally a small follow-up to the existing microg#3784 / microg#3808 integration lineage, not a competing RCS implementation. It preserves the existing contributor ancestry and claims only the cached-state orchestration, strict matching/SIM-slot handling, tests, and the locked-device validation described above.

It does not claim that RCS is Connected end-to-end or that microg#2994 is fully solved.

Refs: microg#2994, microg#3808