hermes - 💡(How to fix) Fix [Feature] Auxiliary provider health check / readiness probe (hermes doctor --auxiliary) [1 pull requests]

Feature Description

Add a hermes doctor --auxiliary command (or extend the existing hermes doctor) that validates the connectivity and correctness of all configured auxiliary task providers.

Problem

When auxiliary providers are misconfigured, failures are silent:

• Vision calls fail at runtime when the user first tries vision_analyze
• Context compression fails mid-session when context grows large
• TTS fails when the user first requests speech output

There is no way to validate auxiliary provider configuration at startup or on-demand.

Proposed Command

$ hermes doctor --auxiliary
✓ vision: glm-4v-flash @ open.bigmodel.cn (152ms)
✓ compression: deepseek-v4-flash @ api.deepseek.com (203ms)
✗ tts: api_key invalid or expired
✓ embedding: text-embedding-3-small @ api.openai.com (89ms)

For each configured auxiliary task:

1. Resolve the provider + client (same path as runtime)
2. Send a minimal test request (e.g., "hello" for chat, a 1x1 pixel for vision)
3. Report success/failure with latency
4. Flag common issues (expired API key, wrong endpoint, parameter mismatch)

Integration

• Run automatically during hermes setup after provider configuration
• Run on hermes gateway startup (non-blocking, log warnings for failed providers)
• Available as hermes doctor --auxiliary for manual diagnostics
• Hook into resolve_vision_provider_client to catch configuration issues before first use

Motivation

I traced a GLM vision issue (#26827) that took extensive debugging because the error only appeared at runtime. A startup health check would have caught it immediately by showing the 1210 error during configuration validation.