Update allowed LLM models

[rowanseymour]

Updates the default LLM_TYPES model lists to reflect current provider catalogs:

Removed (retired by providers, requests now fail):

• claude-3-7-sonnet-20250219, claude-3-5-haiku-20241022 (retired Feb 2026)
• gemini-2.0-flash (shut down Jun 2026), gemini-1.5-flash (1.5 series shut down)

Added:

• Anthropic: claude-opus-4-8, claude-sonnet-5
• Google: gemini-3.6-flash, gemini-3.5-flash, gemini-3.5-flash-lite
• OpenAI: gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna

Also corrects max output tokens for claude-sonnet-4-6 (64K → 128K).

Existing LLM records are unaffected since model and max_output_tokens are stored on the row — this only changes which models can be selected for new connections. Orgs still configured with a retired model were already broken at the provider and will need to reconnect separately.

[claude]

Claude finished @rowanseymour's task in 1m 53s —— View job

---

PR Review

• Load review tools
• Read changed files and consumer code
• Analyze correctness (model IDs, token limits, test coverage)
• Post review

---

Straightforward config change. The LLM_TYPES update is consistent with the test fixtures — Anthropic/Google test mocks were updated in lockstep with the new model IDs, and every LLM.create(...) in test_llm.py / test_llmcrudl.py / api/internal/tests.py was moved off the retired claude-3-5-haiku-20241022 to claude-haiku-4-5-20251001. The filter branches in both wizard tests still exercise the "not in allowed list" path (Anthropic keeps claude-3-5-sonnet-20240620, Google keeps gemini-1.5-flash), so test coverage isn't reduced.

I can't independently verify the max_output_tokens values or that the new model IDs exactly match provider catalogs — you'll want to double-check those against Anthropic/Google/OpenAI docs before merging. The claude-sonnet-4-6 64K → 128K correction is the only field where a wrong number would silently truncate live responses (existing rows keep their stored value, but any newly-created connection would inherit the new cap).

One minor observation, non-blocking:

• temba/utils/management/commands/data/mailroom_db.json:221 still seeds a claude-3-7-sonnet LLM record. This is dev-only seed data and doesn't affect prod (existing LLM.model values are untouched by the settings change, as the PR body notes), but a freshly initialized mailroom DB will reference a model that's no longer in LLM_TYPES and no longer accepted by the provider. Worth updating to claude-haiku-4-5-20251001 or another current model in a follow-up.

Nothing else stands out — no security, performance, or convention concerns.
· Branch: update-llm-models