Support an external credential helper / exec-based auth command for dynamic token injection

### What would you like to be added?

A way to supply the API key/bearer token via an external command that Gemini CLI invokes, rather than only
reading a static value from GEMINI_API_KEY / GOOGLE_API_KEY / ADC once at process start.

Concretely: a setting such as security.auth.credentialHelper in settings.json (or a GEMINI_CREDENTIAL_HELPER
env var) pointing to an executable. Gemini CLI would run it to obtain the current credential:
- On startup, to get the initial token.
- Again on receiving a 401/403 from the configured endpoint, so a long-running session can recover from an
expired token without restarting the CLI.
- The helper's stdout (trimmed) is used as the credential for the next request.

This should compose with the existing GOOGLE_GEMINI_BASE_URL override so it also works when pointed at an
internal gateway instead of Google's endpoint.

### Why is this needed?

Enterprises routing Gemini CLI through an internal gateway (Kong, Portkey, etc.) often authenticate callers
with short-lived OIDC/JWT tokens minted per developer, rather than a static API key. Today there's no way to
give Gemini CLI a token that stays fresh — whatever is in GEMINI_API_KEY at process start is used for the
life of the process, so sessions break when the token expires.

Other CLI agents already solve this the same way: Claude Code has an apiKeyHelper setting that it re-invokes
to fetch the current token rather than caching one for the process lifetime — the same pattern as
credential_process in the AWS CLI or a Git credential helper. Without an equivalent, the only workaround is
running a local proxy per developer machine to inject headers, which doesn't scale well across a large
developer fleet and duplicates logic a client-native hook could handle directly.

(Related but distinct from #1679, which asked for a custom endpoint/header — this is about the credential
being dynamically supplied, not about where it's sent.)

### Additional context

_No response_

Start by locating the settings.json handling and the code that reads GEMINI_API_KEY, GOOGLE_API_KEY, and GOOGLE_GEMINI_BASE_URL before making requests. Trace how authentication errors are handled. Done means an executable can provide the initial trimmed credential and can be re-invoked after a 401/403 so a long-running session recovers.

Written by the indexing model from the issue text.