Bug Description

hermes doctor can falsely report a valid Gemini API key as invalid because the health check uses OpenAI-style Bearer authentication against Google's native Generative Language API.

For Gemini API keys, this is wrong:

Authorization: Bearer <GEMINI_API_KEY>

The native Gemini API accepts API-key authentication via query parameter:

https://generativelanguage.googleapis.com/v1beta/models?key=<GEMINI_API_KEY>

or equivalent Google API-key auth mechanisms.

Expected Behavior

When probing generativelanguage.googleapis.com / Gemini native API, hermes doctor should validate with Gemini-compatible API-key auth, e.g.:

httpx.get(url, params={"key": key}, headers={"User-Agent": ...})

and should not send Authorization: Bearer for Gemini API-key checks.

Actual Behavior

Doctor uses Bearer auth for the Gemini /models probe, causing HTTP 401 even when the key is valid and runtime Gemini calls work.

Reproduction

1. Configure a valid GEMINI_API_KEY.
2. Run hermes doctor.
3. Observe Gemini is reported invalid or unhealthy.
4. Verify the same key directly:

curl "https://generativelanguage.googleapis.com/v1beta/models?key=$GEMINI_API_KEY"

1. Direct Gemini API-key auth succeeds, while Bearer auth fails with 401.

Root Cause

Doctor treats Gemini like a generic Bearer-token provider instead of using Gemini's native API-key authentication convention.

Suggested Fix

In the doctor provider probe, when provider is Gemini or the probe URL host matches generativelanguage.googleapis.com:

• remove the Authorization: Bearer ... header
• send params={"key": key} or another Gemini-supported API-key auth style
• keep existing Bearer behavior for non-Gemini providers

Related Existing Reports / PRs

This is a focused current-main report related to:

• #23354
• #23364
• #20642

Environment

• Hermes Agent current main around commit 4fdfdf674
• Provider: Gemini / Google AI Studio
• Command: hermes doctor