Fix timeouts for named custom providers

[bainianlaoyao]

Summary

• resolve timeout config for named custom providers when runtime provider is custom
• keep per-model timeout and stale-timeout overrides working for model.provider: custom:<name>
• add regression coverage for named custom provider request and stale timeouts

Test

• uv run --extra dev pytest tests/hermes_cli/test_timeouts.py

[teknium1]

Thanks for isolating the normalized-custom timeout regression; current main still has the reported primary-path bug (run_agent.py:1253 → hermes_cli/timeouts.py:56-69).

Problems

• The proposed helper uses config.model.provider as the identity source. Runtime resolution already preserves the actual requested identity (hermes_cli/runtime_provider.py:1612-1619), so the config value can differ from the provider selected for this call.
• This leaves a verified sibling path unfixed: fallback activation keeps custom:name in fb_provider (agent/chat_completion_helpers.py:1378), assigns it to agent.provider (:1507), then calls get_provider_request_timeout(fb_provider, fb_model) (:1554). The PR only translates an ID exactly equal to custom, so providers.custom:name still does not resolve to providers.name.

Suggested changes

• Carry the resolver's requested_provider into the agent and use it as the config lookup identity for named custom providers.
• Add production-path tests for primary, explicit, and fallback named custom selections.

Automated hermes-sweeper review.

[teknium1]

This only handles the generic runtime label custom. Fallback activation can pass custom:name directly to the timeout helper (agent/chat_completion_helpers.py:1378,1554), so this branch is skipped and the lookup remains providers["custom:name"]. Resolve the actual runtime requested-provider identity and normalize custom:name to name instead.