fix: parse token exp claim for expiration clamp

[paulb777]

Description

Fixes #16573

AppCheckCore previously derived a cached token's expirationDate from the local time at which the client happens to process the HTTP response, rather than from the token's own exp claim. Because every downstream validity decision reads only that locally-derived value, any delay between the App Check backend minting a token and the client executing the response handler is silently converted into extra apparent lifetime. This can cause the SDK to serve an already-expired token for up to a full TTL if the process is suspended or stalled between the token request and the response handling.

This PR addresses the issue by explicitly parsing the JSON Web Token (exp claim) from the App Check token payload returned by the server.
It then computes expirationDate = min(jwtExpirationDate, requestDate + ttl) clamping it to the correct bounds.
If the token is a mock token or malformed, it gracefully falls back to the original requestDate + ttl logic.

Changes

• Extracts the JWT exp claim in GACAppCheckTokenExpirationDateFromJWT.
• Modifies initWithResponseDict: inside GACAppCheckToken+APIResponse to compute the clamped expiration date based on the extracted exp.
• Added unit tests to GACAppCheckAPIServiceTests.m: testAppCheckTokenWithAPIResponseValidJWTWithExp and testAppCheckTokenWithAPIResponseValidJWTWithExpGreaterThenTTL to verify correct expirationDate extraction and clamping behavior when a valid JWT payload is intercepted.