fix(model_metadata): override models.dev underreports for MiniMax-M3

[semperaug]

Summary

get_model_context_length() consults models.dev (step 5f) before the hardcoded DEFAULT_CONTEXT_LENGTHS fallback (step 8). For newly-released models, models.dev lags behind on its catalog values — MiniMax-M3 was released 2026-06-01 and models.dev still lists its context window as 512,000 tokens, when the official value is 1,000,000. The hardcoded minimax-m3: 1,000,000 entry in DEFAULT_CONTEXT_LENGTHS is therefore never reached, and the TUI status bar displays 64K/512K instead of the true 64K/1M. Reasoning quality degrades around the 50% mark because Hermes thinks the context is already half-full.

Changes

1. New hardcoded-override guard at step 5f (agent/model_metadata.py:1721-1737)

When models.dev returns a value smaller than what DEFAULT_CONTEXT_LENGTHS has for the same model, trust the hardcode and log. Same pattern as the existing Kimi-family 32k guard at step 6 — generic, so future newly-released models with stale catalog data get auto-fixed without per-model special-casing.

hardcoded = _hardcoded_context_length_for(model)
if hardcoded and hardcoded > ctx:
    logger.info(
        "models.dev context=%s for %r underreports the hardcoded catalog value; "
        "using hardcoded %s",
        f"{ctx:,}", model, f"{hardcoded:,}",
    )
    return hardcoded

2. Widen the M3 stale-cache invalidation threshold at step 1 (agent/model_metadata.py:1554-1566)

From <= 204,800 to < 1,000,000 so existing sessions whose context_compressor cached the 512K value get re-resolved on the next lookup instead of staying stuck at the underreport.

3. New helper _hardcoded_context_length_for() (agent/model_metadata.py:1781-1795)

Extracts the longest-key-first fuzzy-match logic from step 8 into a reusable function so the new step 5f guard uses the exact same precedence rules as the hardcoded fallback.

Why this matters for users

• TUI status bar shows correct context window — X K / 1,000 K for M3 (was X K / 512 K)
• No more premature "50% full" reasoning degradation for any model on newly-released entries
• Generic fix — covers MiniMax-M3 today and any future model where models.dev's catalog hasn't caught up to a release

Verification

>>> get_model_context_length('MiniMax-M3', base_url='https://api.minimaxi.com/v1', provider='minimax-cn')
1,000,000   # was 512,000

>>> get_model_context_length('MiniMax-M2.7', base_url='https://api.minimaxi.com/v1', provider='minimax-cn')
204,800     # models.dev value is correct, unchanged

• Stale cache entry of 512K auto-invalidates and re-resolves to 1M ✓
• 100 tests in tests/agent/test_model_metadata.py and tests/test_minimax_model_validation.py pass ✓
• Pyright + py_compile clean ✓

Related

• MiniMax-M3 official context: 1,000,000 tokens (https://platform.minimax.io/docs/api-reference/text-chat-openai, https://openrouter.ai/minimax/minimax-m3)
• models.dev minimax-cn provider currently lists MiniMax-M3 with limit.context: 512,000 (stale)
• Same pattern as the existing Kimi-family underreport guard at step 6

[semperaug]

Superseded by upstream. The same fix has already landed on main through a series of commits that evolved past this approach:

• 5a4297a11 fix(model_metadata): prefer hardcoded 1M for MiniMax M3 over stale models.dev probe
• b4e59bcc0 fix(model_metadata): prefer hardcoded 1M for MiniMax M3 over stale models.dev probe
• 1ffa22ee6 fix(minimax): drop stale ≤204,800 cache entries for MiniMax-M3 (fix(minimax): drop stale ≤204,800 cache entries for MiniMax-M3 #36726)
• e3b3d4d75 feat(models): add MiniMax-M3 to native minimax providers + 1M context (feat(models): add MiniMax-M3 to native minimax providers + 1M context #36214)
• 0269eca7e test(minimax): assert M3 stale-cache guard contract, not a brittle 1M literal (test(minimax): assert M3 stale-cache guard contract, not a brittle 1M literal #37220)

Upstream's threshold-based probe + native provider registration + contract-based test is more robust than the hardcoded literal in this PR. Closing as implemented_on_main.