feat: return 1M context for Claude Opus 4.6/4.7/4.8 families

[dgageot]

DefaultClaudeContextLimit in pkg/modelinfo/modelinfo.go returned the 200k fallback for Claude Opus 4.6, 4.7, and 4.8 when models.dev had no catalogue entry, even though these models expose a 1,000,000-token context window. That fallback feeds the Anthropic client's max_tokens clamping on the context-overflow retry path, so a stale 200k value could clamp max_tokens too aggressively on models that can handle much more.

DefaultClaudeContextLimit now returns 1,000,000 for the claude-opus-4-6, claude-opus-4-7, and claude-opus-4-8 families, matching the existing claude-fable handling. Bedrock-style inference-profile IDs (e.g. global.anthropic.claude-opus-4-8-...) are also recognised by stripping the profile prefix before the family check.

As a small follow-on, the Opus 4.6/4.7/4.8 prefix matching that was previously duplicated between RejectsTokenThinking and DefaultClaudeContextLimit is extracted into a shared unexported helper isClaudeOpus46To48, backed by a package-level claudeOpus46To48Prefixes slice. Adding support for a future Opus version now requires a single-line change in one place.

[docker-agent]

Assessment: 🟢 APPROVE

The isClaudeOpus46To48 helper extraction is clean and the prefix-boundary check (== prefix || HasPrefix(prefix+"-")) correctly rejects false positives like claude-opus-4-60. Both RejectsTokenThinking and DefaultClaudeContextLimit now delegate to the shared helper consistently. Bedrock inference-profile ID stripping works correctly. Test coverage is thorough.

No high- or medium-severity issues found.

ℹ️ Low-severity observations (no action required)

pkg/modelinfo/modelinfo.go:294 — Double Bedrock prefix strip is harmless but redundant

DefaultClaudeContextLimit calls bedrockClaudeModelName to strip the Bedrock prefix into m, then passes m to isClaudeOpus46To48, which internally calls bedrockClaudeModelName again. The double-strip is a no-op with current model naming conventions (a bare claude-* name will never look like a Bedrock profile ID), but it creates a subtle coupling: if a future bedrockClaudeModelName could produce output matching the Bedrock pattern, the inner call would strip further. Consider either passing the already-stripped bare name directly, or documenting that isClaudeOpus46To48 accepts both raw and pre-stripped IDs.