docs: document auxiliary_client api_key_env bug + workaround

_resolve_task_provider_model() in agent/auxiliary_client.py ignores
api_key_env for auxiliary tasks (vision, compression). The custom
provider path resolves it, but aux tasks take a different code path.

Workaround: set api_key directly alongside api_key_env.
Applied to Tanko (vision + compression).

hermes-key-enforcement.prose.md

@@ -189,3 +189,37 @@ auth → validate → lint → ai-review → gate
 - **Status check**: `PR Pipeline — Authorize → Validate → Review → Merge` required before merge
 - **Runner**: `runner-ct110` (Gitea Actions v0.6.1) on CT 110
 - **Config**: `.gitea/workflows/pr-pipeline.yaml`
+
+## Known Bug: auxiliary_client ignores api_key_env (2026-07-05)
+
+**Bug**: `_resolve_task_provider_model()` in `agent/auxiliary_client.py` reads
+`api_key` from auxiliary task configs (vision, compression, etc.) but does NOT
+resolve `api_key_env`. The custom provider resolution path handles `api_key_env`,
+but auxiliary tasks take a different code path that ignores it.
+
+**Impact**: Vision analysis and compression calls fall through to the `"no-key-required"`
+placeholder, causing 401 errors on LiteLLM/harness (which require `sk-*` keys).
+
+**Workaround**: Set `api_key` directly alongside `api_key_env` in each auxiliary
+task config:
+
+```yaml
+auxiliary:
+  vision:
+    api_key: sk-CggiHWlamQyShxWC3Hx6uw      # ← workaround
+    api_key_env: LITELLM_API_KEY
+    base_url: http://192.168.68.116/v1
+    model: gemma-4-12b
+    provider: harness
+  compression:
+    api_key: sk-CggiHWlamQyShxWC3Hx6uw      # ← workaround
+    api_key_env: LITELLM_API_KEY
+    base_url: http://192.168.68.116/v1
+    model: gemma-4-12b
+    provider: harness
+```
+
+**Affected agents**: All Hermes agents with harness/LiteLLM provider and
+`api_key_env` in auxiliary configs (Tanko confirmed, Mumuni/Baggy/Tdunna unchecked).
+
+**Source location**: `agent/auxiliary_client.py` line 5478