fix(agent): accept dimension-correct image shrinks (#48013)

[Tranquil-Flow]

What

Fixes #48013 by making image-shrink recovery evaluate success against the constraint that triggered the resize.

When Anthropic/OpenRouter reports the many-image 2000px dimension cap, Hermes already calls the shrink path with max_dimension=2000. The bug was one layer lower: _shrink_data_url rejected a dimension-correct PNG downscale if the re-encoded data URL was larger in bytes than the original, leaving oversized screenshots in the request and consuming the one-shot retry.

How

• Track whether a data URL needs shrinking because of byte size or pixel dimension.
• For byte-triggered shrink, preserve the existing byte-growth rejection behavior.
• For dimension-triggered shrink, verify the resized image is within max_dimension and accept it even if bytes grew.
• Treat dimension-shrink failures as unshrinkable too, so partial progress does not burn the single retry on a request that will still 400.

Verification

Red/green proof:

• Without the production change, test_dimension_shrink_with_byte_growth_accepted fails with assert False is True.
• With this change, the focused suite passes:
  • /Users/evinova-self/.hermes/hermes-agent/venv/bin/python3 -m pytest tests/run_agent/test_image_shrink_recovery.py -v -o "addopts=" --tb=short
  • Result: 19 passed, 1 warning in 1.00s

Publication gates:

• Same-author duplicate check for issue Image-dimension 400 bricks sessions: shrink recovery discards a pixel-correct downscale when re-encoded PNG bytes grow (survives #45979) #48013: none found.
• Same-author branch duplicate check for fix/48013*: none found.
• Competitor/topic search for 48013 and distinctive image-dimension shrink terms: none found.

Auto-published by Moonsong via Path B automated pipeline.

[teknium1]

Merged via #49140 (commit 990273d) — closes #48013. Your PR was submitted first and carried the same core idea (key the accept/reject gate on the binding constraint and accept a dimension-correct downscale). #49140 authors that approach cleanly against current main and additionally closes the bytes-path gap (a byte-shrunk image that's still over the per-side cap). Credited in the merged PR body. Thanks for the original insight!