fix(model): invalidate stale MiniMax-M3 cache entries up to 512K

[annguyenNous]

Fixes #43400

Problem

MiniMax M3 supports 1M context, but Hermes displays 512K. The root cause is a stale cache entry:

1. models.dev reports MiniMax-M3 context as 512K, which gets persisted to the context cache
2. The cache invalidation threshold at model_metadata.py:1621 was cached <= 204_800
3. Since 512K > 204K, the stale cache entry survived invalidation
4. On subsequent lookups, the cached 512K value was returned instead of the correct 1M from the hardcoded catalog

Fix

Change the cache invalidation threshold from a hardcoded <= 204_800 to a dynamic comparison against the catalog value (DEFAULT_CONTEXT_LENGTHS["minimax-m3"] = 1M). Any cached value below the catalog entry is now invalidated and re-resolved.

Testing

• Syntax verified: ast.parse() passes
• The change is backward-compatible: if the catalog entry changes, the threshold auto-adjusts

[alt-glitch]

Related: competing fix for #43400 with #43464. This PR widens the stale-cache invalidation threshold to the catalog value; #43464 prefers OpenRouter metadata before models.dev. Both target the same MiniMax-M3 512K-vs-1M resolution bug — part of the saturated M3 context cluster (#37289, #38298, #37235, #37335). Maintainer should pick one mechanism.

[austinpickett]

Closing in favour of #43464 ('[verified] fix minimax m3 context resolution'), which is the canonical fix for this bug and has been approved.

Relationship analysis: Both PRs touch agent/model_metadata.py but at different locations:

• This PR (fix(model): invalidate stale MiniMax-M3 cache entries up to 512K #43469) modifies the stale-cache invalidation block (~line 1621): widens the invalidation condition from cached <= 204_800 to cached < DEFAULT_CONTEXT_LENGTHS.get("minimax-m3", 1_000_000), which also catches the models.dev 512K misreport.
• [verified] fix minimax m3 context resolution #43464 modifies the resolution-order block (~line 1118): inserts an OR-catalog lookup before models.dev for MiniMax providers, attacking the root cause upstream.

#43464 is the more complete and correct fix. Your cache invalidation widening (204K → <1M) is a valid guard for already-persisted stale entries, but the coverage is subsumed: once #43464 lands, new resolutions will go through OR and cache the correct value. The widened boundary is a nice-to-have that can be re-evaluated as a follow-up if any users still hit stale-cache issues post-merge of #43464.

[austinpickett]

✅ Approved

What it fixes: The stale MiniMax-M3 cache invalidation threshold was <= 204_800. models.dev can return 512K for M3, which also gets cached as a stale pre-catalog value. The fix raises the threshold to < DEFAULT_CONTEXT_LENGTHS.get('minimax-m3', 1_000_000) — dropping any value below the canonical 1M entry.

Correctness: The threshold is read from the catalog dict itself, so if the catalog value ever changes the threshold tracks automatically. Falls back to 1M if key missing.

Note: PR #43464 also touches model_metadata.py at line ~1118 (resolution priority path) — these are different code locations (invalidation block vs. resolution block), not a semantic conflict. Both can merge cleanly.

Reviewed by Hermes Agent