fix(google-auth-library): sign with the client_email from a JSON keyFile

[Marinski]

Fixes #9469

Description

Since 10.6.1, a JWT client given only a JSON keyFile signs its token assertion without iss, and Google rejects it with invalid_grant: account not found.

GoogleToken copies email into iss in its constructor, before the key file has been read. TokenHandler.processCredentials() then sets email from the file, but not iss, which is the claim that gets signed. This change restores the standalone gtoken behaviour: iss = clientEmail || iss. An iss passed in explicitly is kept when the key file has no email, for example a PEM file.

Changelist

• src/gtoken/tokenHandler.ts: set tokenOptions.iss from the key file's client_email.
• test/gtoken/test.tokenHandler.ts: assert that iss is set from the key file, and that a given iss is kept when the file has no email.
• test/test.jwt.ts: end to end, a JSON keyFile with no email option signs iss = client_email. Every existing keyFile test also passed email, which is why this wasn't caught.

Both new assertions fail without the fix and pass with it. The gtoken and jwt suites pass: 131 tests.

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request updates the TokenHandler to ensure that tokenOptions.iss is correctly set using the client email from credentials when available, and adds corresponding unit tests to verify this behavior. The feedback suggests wrapping the temporary directory cleanup in a try...finally block in the new JWT test to prevent directory leaks in case of test failures.