fix(delegation): normalize child runtime tuple

[dorukardahan]

Summary

Normalizes the delegated child agent runtime tuple before constructing AIAgent:

• resolves stale inherited base_url / api_key / api_mode through Hermes' runtime provider resolver
• preserves explicit delegation.base_url and ACP transport overrides
• infers provider from model before normalization when needed
• keeps same-provider explicit endpoint cases intact

Root cause

v0.18.0 can construct a child with the intended provider/model but a stale parent endpoint or key after a parent route switch. That produces a subtly wrong runtime tuple: provider/model say one thing, but base_url / credential pool still point somewhere else.

Related merged precedent

• fix(delegation): route native-SDK providers through runtime resolver; fail on '(empty)' sentinel #56135 fixed another delegation/runtime-resolver gap for native SDK providers and used the same reviewer-friendly shape: small change in tools/delegate_tool.py plus focused regression tests.
• feat(delegate): remove model-facing toolsets arg — subagents inherit parent's #56386 and feat(delegation): unify concurrency caps — deprecate max_async_children #56955 show delegation changes are landing when they are scoped and covered by tests/tools/test_delegate.py.

Scope / risk

• Normalization runs only for inherited/default delegation runtime values.
• Explicit delegation endpoint overrides remain authoritative.
• ACP transport override behavior is preserved.

Verification

• python -m pytest tests/tools/test_delegate.py
• python -m py_compile tools/delegate_tool.py
• git diff --check
• GitHub: all required checks pass on current head eb0ad009e89a

[wesleysimplicio]

Read-only review pass: one remaining edge case seems to preserve the stale key this PR is trying to eliminate.

_normalize_child_runtime_tuple only repairs the inherited tuple when URL/mode/provider shape mismatches. If base_url and api_mode already match the resolved runtime but the inherited api_key is stale, the helper returns the old key. I reproduced this in a local read-only checkout by patching the resolver to return fresh-key; the helper still returned stale-key because no URL/mode mismatch was present.

I would include api_key mismatch in the repair condition whenever the resolver provides a key, plus a targeted regression for inherited stale key with matching base URL and API mode.

[dorukardahan]

thanks, good catch. i added a follow-up commit that includes the api_key mismatch in the normalization condition and a regression test for the matching URL/mode case.\n\nwhile testing this on my live Hermes setup, i also found a related credential pool edge case: after a parent route switch, parent.provider can be openai-codex while the inherited pool is still from the previous provider. i added a small guard so child agents only share the parent pool when the pool provider matches too.\n\nlocal checks after the follow-up commit:\n- scripts/run_tests.sh tests/tools/test_delegate.py -> 132 passed\n- .venv/bin/ruff check tools/delegate_tool.py tests/tools/test_delegate.py -> passed

[teknium1]

Thanks for the focused delegation investigation and the follow-up coverage for stale keys and pools. This is an automated hermes-sweeper review; current main already provides the requested runtime consistency guarantees.

• 25b7348457fc3874f66555d141fd170ccef1e875 added active-endpoint inheritance in tools/delegate_tool.py:1201; tests/tools/test_delegate.py:1542 verifies a child uses the parent's live client endpoint rather than stale parent.base_url.
• a23d5073fbd2efa133f96fd60ad172799de062e7 makes agent/agent_runtime_helpers.py:1816 reject a provider switch that would retain an old endpoint, and reloads the pool for the new provider at :1850.

Those current-main fixes cover the stale delegated runtime tuple and stale credential-pool behavior addressed here.