fix(agent): honour fallback entry context_length on failover activation

[gaogage]

What does this PR do?

try_activate_fallback clears the per-config context_length override before switching models, so the fallback model resolves its real context window instead of inheriting the stale value from the previous model (#22387).

However, the clear is unconditional. When the fallback chain entry itself carries an explicit context_length (a user-configured per-fallback value), that value is dropped as well, and get_model_context_length() falls through to the hardcoded 256K default. Explicit per-fallback context_length is most commonly set for custom/self-hosted models that are not in any known catalog — exactly the models that cannot fall back to catalog resolution — so after a failover their context window is silently mis-reported as 256K.

This PR keeps the #22387 clearing behaviour but first captures the fallback entry's own context_length and restores it after the clear:

• fallback entry has explicit context_length → honoured (user config wins)
• fallback entry has none → cleared override, catalog resolution proceeds as designed

Related Issue

Follow-up to #22387

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/chat_completion_helpers.py (try_activate_fallback): capture fb.get("context_length") before clearing agent._config_context_length, restore it afterwards when present and parseable

How to Test

1. Configure a model with a fallback chain entry that sets an explicit context_length (e.g. a custom endpoint model with a 128K window) whose primary model uses a different context_length
2. Trigger the failover (fail the primary)
3. Before: the fallback model's context window resolves to the 256K default, ignoring the per-fallback value
4. After: the fallback model honours the entry's context_length; entries without one behave exactly as before

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — not run locally (live-install environment); happy to iterate if CI flags anything
• I've added tests for my changes — open to adding one for try_activate_fallback if maintainers point at the preferred seam
• I've tested on my platform: macOS (Darwin 25.6.0, arm64)

Documentation & Housekeeping

• N/A — no docs, config keys, architecture or tool-schema changes

[alt-glitch]

This was generated by AI during triage.

Duplicate of #70256: both patches preserve an explicit fallback-entry context_length during try_activate_fallback rather than dropping it with the prior model override.