[devragrin] [GmsCore] Implement guardWithRequest service path (#2851)

[kwanter]

/claim #2851

Summary

• Implement the previously stubbed IDroidGuardService.guardWithRequest so request-backed DroidGuard flows (e.g. Play Integrity multi-step attestation) can execute.
• Wire it to the existing handle lifecycle: getHandle() → initWithRequest with fallback to init → snapshot → onResult, with close in a finally block.
• On error, deliver an empty byte array through callbacks.onResult(...) to match the existing KeyRetrievalService error convention and avoid binder exceptions.

Why

guardWithRequest was a literal TODO("Not yet implemented"), causing any caller that uses the request-backed path to throw NotImplementedError. The remote DroidGuard path is the only way to obtain Play Integrity tokens at a higher level on a microG-only device, and multi-step Play Integrity flows (the common case for Firebase AppCheck-backed apps such as Dott) hit this exact code path.

Test Plan

• Build the module: ./gradlew :play-services-droidguard-core:compileDebugKotlin
• Run unit tests: ./gradlew :play-services-droidguard-core:testDebugUnitTest
• Manual: trigger a Play Integrity / Firebase AppCheck flow (e.g. Dott sign-in) with the remote DroidGuard runtime mode enabled in microG settings. Compare behavior before and after the change.
• Verify: existing single-step flows (SafetyNet attestation, etc.) continue to use the guard() path and are unaffected.

Metadata note

Public issue/repo context only. No private prompts, memory, credentials, or hidden runtime context are disclosed. PR is intended to be evaluated on its own merits against issue #2851.

Bounty: claimed via BountyHub for the $100 total listed on this issue.

[kwanter]

Update / implementation note:

This PR intentionally keeps #2851 narrow: it only replaces the missing guardWithRequest runtime path with the existing DroidGuard handle lifecycle.

Runtime flow implemented:

getHandle() -> initWithRequest(flow, request) -> snapshot(map) -> callbacks.onResult(bytes) -> close()

If initWithRequest returns null, it falls back to the existing init(flow) path before snapshotting. Errors return an empty byte array via the callback instead of throwing through binder, matching the existing error-tolerant service pattern.

Reason for the small diff:

• no AIDL/API surface changes
• no new session lifecycle assumptions
• no docs-only change
• uses existing DroidGuardHandleImpl / RemoteHandleImpl behavior already present in the codebase

Happy to expand this if maintainers want explicit multi-step session APIs, but this should address the immediate TODO("Not yet implemented") failure path hit by request-backed Play Integrity / remote DroidGuard callers.