feat(delegation): independent fallback chain for subagents

[motochan]

What does this PR do?

Adds delegation.fallback_providers so subagents can run on a fallback chain that differs from the parent agent's top-level fallback_providers.

Today _build_child_agent unconditionally passes the parent's _fallback_chain as the child's fallback_model, so a subagent pinned to a cheap/fast provider still fails over to the main agent's fallback models instead of a subagent-appropriate backup.

Concrete use case: main agent runs openrouter/deepseek-v4-pro-0813 with openrouter/glm-5.2 as fallback, while subagents run openrouter/deepseek-v4-flash-0731 and should fail over to a local ascent-dspark endpoint — not to the main agent's fallback chain.

Related Issue

Fixes #65038

Type of Change

• ✨ New feature (non-breaking change that adds functionality)
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)

Changes Made

• hermes_cli/config_defaults.py — new delegation.fallback_providers: [] default (empty = inherit parent chain, backward compatible)
• tools/delegate_tool.py — _normalize_delegation_fallback_chain() validates entries against the provider+model contract; _resolve_delegation_credentials() forwards the chain; _build_child_agent() accepts override_fallback_providers and falls back to the parent chain when unset/empty; delegate tool description mentions the knob
• tests/tools/test_delegate.py — 3 new tests: override wins, empty list inherits parent chain, malformed entries are dropped
• website/docs/user-guide/configuration.md + website/docs/user-guide/features/fallback-providers.md — document the new key

[alt-glitch]

This was generated by AI during triage.

Related to #65052 and #81072: this implements the same per-child fallback-chain goal, but its [] semantics inherit the parent chain while those PRs use [] to explicitly disable child fallback. Maintainers should choose the configuration contract before consolidation.

[ayushnangia]

Welcome, and thanks for the concrete use case — it's a good one. Heads-up for coordination: this feature already has three prior implementations, so reviewers will want the family ordered rather than re-derived:

• fix(delegation): honor delegation.fallback_providers for child agents (#65038) #65052 (July 16) — delegation.fallback_providers for delegated children: same feature, same files (config_defaults, delegate_tool, tests, the two docs pages), including null/empty inheritance semantics
• fix(delegation): resolve child fallback chains through the full pin x config matrix (#80450) #80479 — the runtime resolution matrix for child fallback chains (_resolve_child_fallback_chain, pin × config decision table)
• test(delegation): executable class map for fallback-chain resolution (#80450) #80474 — the executable class map tracking the whole delegation-fallback class
• fix(delegation): honor delegation.fallback_providers for child agents #80421 (@andrexibiza) — an earlier reimplementation of the same config hook, credited

Your PR's diff overlaps #65052 almost file-for-file, so one of them will need to absorb the other. Options, your pick: fold into #65052 as a co-authored update (your use case + tests would strengthen it), coordinate with me on a landing order, or leave both for maintainers to adjudicate. Happy to review yours either way — the _build_child_agent failover point is exactly where #65052 hooks too.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

feat(delegation): independent fallback chain for subagents

• tools/delegate_tool.py (~L1590): child_fallback = override_fallback_providers or parent_fallback means a config that normalizes to [] (empty, or all entries malformed) silently inherits the parent chain — there is no way to express "subagents must NOT fall back" when the parent has a chain. Docs say empty = inherit, so this is intentional, but consider documenting that disabling subagent fallback isn't expressible (or adding a null/sentinel for "no fallback").
• _normalize_delegation_fallback_chain drops malformed entries silently, and delegate_task then converts the result to None, so a config typo (e.g. model under a wrong key) silently reverts to parent inheritance with no log. A logger.warning when entries are dropped would make misconfiguration visible.
• The normalized chain copies arbitrary extra keys (base_url, api_key, unknown keys) untouched while validating only provider/model. A key typo like baseurl is silently carried into fallback_model, where the child likely ignores it — consistent with the top-level contract, but validating the known optional keys too would catch typos.