fix(agent): retry 413 after stripping vision payloads (#47339)

[Tranquil-Flow]

Summary

• Retry 413 recovery by stripping retained tool-message image payloads when context compression cannot reduce the request further.
• Preserve text context from the tool result while evicting image_url / input_image bytes from the retry payload.
• Keep the existing provider-list-content rejection learning separate from 413 payload-size recovery so a too-large request does not permanently mark a vision-capable model as unable to accept list-type tool content.

Verification

• /Users/evinova-self/.hermes/hermes-agent/venv/bin/python3 -m pytest tests/run_agent/test_413_compression.py -v -o "addopts=" --tb=short — 25 passed, 1 warning.
• Regression red proof from build artifacts: the new production-path test failed on upstream/main with Payload too large and cannot compress further before the fix.

Competitor / duplicate check

• Same-author issue search: no open Tranquil-Flow PRs referencing 413 Request Entity Too Large: context compression doesn't evict image/vision payloads — fails even at ~44k tokens on Copilot #47339.
• Same-author branch search: no open fix/47339* PRs.
• Open PR search for 47339, 413 vision payload compression browser_vision: no competing open PRs found.

Auto-published by Moonsong via Path B automated pipeline.

[alt-glitch]

Related: #47398, #42509, #37412 (all fix #47339 — context compression not evicting image/vision payloads, leading to HTTP 413).

Same goal, different mechanism: this PR strips retained tool-message image payloads at the 413 retry-recovery level (conversation_loop.py / run_agent.py), while #47398 fixes the root cause in _strip_historical_media (context_compressor.py) so tool-result _multimodal envelopes are evicted during compression. #42509 and #37412 take an inline-image-shrink approach. Not a duplicate — these are complementary/competing approaches for the maintainer to choose between.

[teknium1]

Merged via #56270 (commit 122e5bc) with your authorship preserved via rebase-merge.

Your fix was cherry-picked onto current main — the 413 recovery path had moved to a token-aware compression check since you opened this, so the strip+retry was placed onto that current else branch. Live E2E confirmed the production path: a real 413 mid-loop with a browser_vision screenshot triggers the eviction (remember_model=False, no false poisoning of the list-content set) and recovers. Thanks for the clean, well-reasoned fix!

[kshitijk4poor]

Superseded by #56293, which carries your commit verbatim (authorship preserved) rebased onto current main. Verified as a sound standalone 413 backstop for #47339 — the root cause (protected-tail images surviving compression) is still unfixed on main; your strip handles both image_url/input_image shapes, preserves text, and the remember_model=False learning-separation is real and tested. Complementary to the shrink PRs (#42509/#37412) and the closed root-cause #47398, not a duplicate. Phase 2c review: 0 Critical. Full credit to you.