chore(tests): add read-only VCR cassette episode-diff diagnostic

[mateo-berri]

Summary

Investigating why CI keeps spending on live gpt-image-1 calls. This adds a read-only diagnostic that dumps VCR cassettes from the cassette Redis and diffs each cassette's episodes field-by-field, to root-cause why the async image-edit cassettes (tests/image_gen_tests/test_image_edits/*) accumulate dead episodes despite #28110's boundary-pinning fix.

The script (scripts/diff_vcr_cassette_episodes.py):

• SCANs cassette keys under litellm:vcr:cassette:tests/image_gen_tests/test_image_edits/* (glob overridable via argv)
• For each cassette, groups episodes by (method, path) and prints per-episode body length + sha
• For multipart bodies, splits on the boundary and reports field-level variation (boundary token, model, prompt, image[] bytes…), flagging the field that <-- VARIES across episodes
• Strictly read-only: issues SCAN / GET / TTL / STRLEN only — never writes or deletes, safe against production cassette Redis

CASSETTE_REDIS_URL=redis://... python scripts/diff_vcr_cassette_episodes.py

Context

The async image-edit cassettes carry many dead episodes (e.g. entries=15/30 with only played=1/2). They're currently stable HITs, so today's CI logs only show iteration noise — they don't reveal what originally varied. The per-episode body-hash diagnostic that would have answered this was added then reverted in #28110. This script inspects the saved cassettes directly so we can pinpoint the non-determinism (boundary token vs. re-encoded image[] payload) without a CI round-trip.

Test plan

• Run against the cassette Redis and confirm it lists the test_image_edits/* cassettes and prints field-level variation
• Verify the flagged <-- VARIES field matches the suspected non-determinism source

https://claude.ai/code/session_01FmWLPEiWJDzQt7hMsMKN8c

---

Generated by Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing claude/gpt-image-1-costs-hYxer (7d7e0b7) with litellm_internal_staging (3bcfe41)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[devin-ai-integration]

🚅 Hi, thanks for the PR! I'm Agent Shin, the automated triage bot for this repository. What's this and why am I getting it?

I read the description against our contribution rubric. Here's how it lined up:

What you got right:

• ✅ Clear problem description
• ✅ Expected vs. actual behavior

What's still missing:

• linked GitHub issue or equivalent explicit issue reference
• end-to-end QA proof with screenshots, video, or real command output
• actual test output from running the diagnostic against the cassette Redis

The PR clearly explains the problem and what the script is meant to reveal, so context is present. However, it only includes a test plan checkbox and a command example without any real output or visual proof, which does not satisfy the required end-to-end QA evidence.

If the description isn't updated in the next 24 hours, I'll auto-close this PR. That's not us saying we don't care about the change; we want the open-PR list to mirror what a maintainer can act on right now, so contributors don't get lost in a backlog. A closed PR is a soft "park this for later," not a rejection. Take your time; everything below still works after the close.

During the grace period: just update the PR description with the missing pieces. No need to ping me; I'll re-check on the next sweep and skip the auto-close if it now passes. See what counts as QA proof for the full rubric (a linked issue alone isn't enough; it covers context, not proof).

If the PR does get auto-closed in 24 hours, you still have easy recovery paths:

• Comment @agent-shin reconsider after updating the description. I'll re-evaluate and reopen the PR if it now passes.
• Comment @greptileai to request a fresh Greptile review; that still works even after the PR is closed, and a stronger score is one of the signals that lifts the PR back into the queue. So a low Greptile score isn't a blocker either.

Internal BerriAI contributors: this rubric doesn't apply to you; ping a maintainer.

(I'm an LLM, so I'm not infallible. If you think I got this wrong, ping a maintainer; they'll override me.)