fix: honour HERMES_LLM_BASE_URL in runtime_provider.py api_key resolution path

[OmarB97]

What changed

Adds a HERMES_LLM_BASE_URL env var fallback in hermes_cli/runtime_provider.py at the env_url resolution step (line 1155). When the provider-specific env var (e.g. OPENCODE_ZEN_BASE_URL) is unset, the code now reads the generic HERMES_LLM_BASE_URL before falling back to the hardcoded pconfig.inference_base_url.

Why

MeshBoard's stream-tap launcher creates a per-dispatch sandbox whose .env sets HERMES_LLM_BASE_URL to a local loopback proxy URL (e.g. http://127.0.0.1:55176). Hermes was ignoring it because:

1. The launcher sets HERMES_LLM_BASE_URL in the subprocess env
2. The sandbox .env also sets it (dotenv loads with override=True)
3. But resolve_runtime_provider() never reads HERMES_LLM_BASE_URL — it only checks pconfig.base_url_env_var (provider-specific) and then falls back to the hardcoded default URL

This caused the stream-tap proxy to receive zero traffic, leaving the dashboard stream rows completely silent during active dispatches.

The earlier fix (commit a73ee55c2) added the fallback to hermes_cli/auth.py:resolve_api_key_provider_credentials() — but the caller at line 1163 already set base_url = env_url or pconfig.inference_base_url BEFORE creds were consulted. The creds base_url was never used for non-kimi providers because line 1169's guard if not base_url: was already False.

How to Review

1. Verify the fallback is scoped correctly: only fires for api_key auth_type providers
2. Verify explicit_base_url (user-passed) still wins over the env var
3. Verify the existing kim-coding branch is unaffected (it takes a different path)
4. Run: cd tests && python3 -m pytest hermes_cli/test_runtime_provider*.py -x --tb=short

Evidence

• Manual test: HERMES_LLM_BASE_URL=http://127.0.0.1:9999 python3 -c "from hermes_cli.runtime_provider import resolve_runtime_provider; r = resolve_runtime_provider(requested='opencode-zen'); print(r['base_url'])" should print http://127.0.0.1:9999 instead of the default opencode-zen URL.

HERMES_LLM_BASE_URL=http://127.0.0.1:9999 python3 -c "
import os, sys; sys.path.insert(0, '.')
from hermes_cli.runtime_provider import resolve_runtime_provider
r = resolve_runtime_provider(requested='opencode-zen')
print('base_url:', r['base_url'])
"

# Without the env var, default URL should be used
python3 -c "
import os, sys; sys.path.insert(0, '.')
from hermes_cli.runtime_provider import resolve_runtime_provider
r = resolve_runtime_provider(requested='opencode-zen')
print('base_url:', r['base_url'])
"

Verification

python3 -m pytest tests/hermes_cli/test_runtime_provider_resolution.py -x --tb=short 2>&1 | tail -5

Pass expected: existing resolve-runtime tests unaffected (env var only activates when provider-specific var is absent).

Risks / Gaps

• stream-tap-runtime-provider-env-override — MeshBoard companion PR setting HERMES_SKIP_PROFILE_OVERRIDE=1 so the sandbox HERMES_HOME is not clobbered by _apply_profile_override()
• hermes-llm-base-url-env-override — This task (close on merge)

Collaborators

Participants: ko-mac.hermes (launcher), MeshBoard stream-tap worker
Process: MeshBoard autopilot dispatch → stream-tap proxy → Hermes subprocess
Task context: stream-tap-empty-jsonl-diagnostic (resolved root cause: Hermes bypassed tap due to missing env var consumption)
Related work: hermes-agent PR #33986 (HERMES_SKIP_PROFILE_OVERRIDE), fork main commit a73ee55 (auth.py fallback)

[github-actions]

🔎 Lint report: fix/hermes-llm-base-url-env-override vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 9544 on HEAD, 9544 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5030 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.