fix(auxiliary): forward explicit_api_key to _try_openrouter for credential pool fallback

[liuhao1024]

Summary

resolve_provider_client() receives explicit_api_key from the credential pool and correctly propagates it to most downstream provider calls. However, when routing to OpenRouter, it calls _try_openrouter() without passing explicit_api_key, silently ignoring it.

This causes auth failures when the auxiliary client falls back to OpenRouter using a runtime API key from the credential pool — the key is available but never reaches the OpenRouter client constructor.

Root Cause

In agent/auxiliary_client.py, the OpenRouter branch of resolve_provider_client() (line ~2058):

if provider == "openrouter":
    client, default = _try_openrouter()  # explicit_api_key not passed

_try_openrouter() only checked the credential pool and OPENROUTER_API_KEY env var — it never accepted an explicit key parameter.

Fix

1. Added explicit_api_key parameter to _try_openrouter(). When provided, it's used directly (bypassing pool/env lookup).
2. resolve_provider_client() now passes explicit_api_key to _try_openrouter().

Test Plan

• New regression test test_explicit_api_key_used_for_openrouter — RED on main, GREEN with fix
• All existing test_auxiliary_client.py tests pass (107 passed, 5 pre-existing failures unrelated to this change)
• No new test regressions in tests/agent/ (2290 passed vs 2289 on main — +1 is the new test)

Closes #18338

[teknium1]

Closing in favour of the narrower fix in #18768 (salvage of your earlier #18341).

#18341's approach — threading explicit_api_key through the existing pool-first, env-fallback flow as explicit_api_key or ... — is cleaner than the short-circuit branch in this PR and has equivalent test coverage. Thanks for both attempts at the fix!

#18768