fix(aux): resolve key_env/api_key_env in auxiliary task config

[DatTheMaster]

Summary

_resolve_task_provider_model() reads per-task config from auxiliary.<task>.api_key but ignores the key_env and api_key_env fields — the documented way to reference an environment variable by name instead of hardcoding the key value.

Every other code path that resolves provider credentials already handles these fields:

• resolve_provider_client() — providers.<name>.key_env / api_key_env
• agent_init.py — fallback entries key_env / api_key_env
• chat_completion_helpers.py — fallback key_env / api_key_env
• hermes_cli/providers.py — provider registry key_env

This PR adds the same resolution to _resolve_task_provider_model(), so that:

auxiliary:
  title_generation:
    provider: openrouter
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY

actually resolves the key from the environment, instead of silently ignoring it and sending requests with no auth (HTTP 401).

What changed

• agent/auxiliary_client.py — After reading cfg_api_key from task config, resolve key_env / api_key_env when no explicit api_key is set. 10 lines added.
• tests/agent/test_auxiliary_client.py — 4 new tests in TestResolveTaskProviderModelKeyEnv.

Testing

Four test cases:

1. key_env resolves to the env var value ✓
2. api_key_env alias resolves identically ✓
3. Explicit api_key takes precedence over key_env ✓
4. Missing env var → api_key is None (graceful, not the literal var name) ✓

Notes

Previous iterations of this fix were in #28766 (closed as duplicate of #24088) and #24088 (stale branch, never merged). This PR is a clean rebase onto current main — just the 10-line fix + tests, no unrelated changes.

Closes #20139

[alt-glitch]

Supersedes #24088 (stale branch, same bug) and #28766 (closed as dupe of #24088, same author). Clean rebase with just the 10-line fix + tests. Related: #16256, #16308 (same _resolve_task_provider_model code path, different facets).

[mxnstrexgl]

LGTM — automated review passed. No security, quality, or test coverage issues detected.

[teknium1]

Thanks for the focused credential-resolution fix. Current main still reads only auxiliary.<task>.api_key in _resolve_task_provider_model() (agent/auxiliary_client.py:5895-5901), while the resulting cfg_api_key is the only configured credential propagated through its return paths (agent/auxiliary_client.py:5976-5987). The proposed key_env / api_key_env lookup matches the existing named-custom-provider convention at agent/auxiliary_client.py:4733-4735, and explicit keys are consumed by provider resolution (agent/auxiliary_client.py:4547-4558, agent/auxiliary_client.py:4890-4897).

Automated hermes-sweeper review.

[DatTheMaster]

Conflict resolved.. happy to help

[OutThisLife]

Closing as superseded by #67192 (merged, salvage batch item 3 / originally #66655): _resolve_task_provider_model now resolves key_env / api_key_env when api_key isn't set directly, so auxiliary tasks (vision/compression/etc.) stop 401'ing.