Add support for `opus` and `opusplan` model aliases in the `claude` engine

[yskopets]

🤖 This issue has been opened by Claude Code.

Summary

The opusplan Claude Code CLI alias is not recognized by the AWF gateway when set via ANTHROPIC_MODEL, causing it to be silently downgraded to a Sonnet model.

Current behavior

opus works as expected — it is a defined alias in the model table and resolves to Claude Opus models correctly.

opusplan, however, is a Claude Code CLI internal alias (meaning: use Claude Opus with extended thinking enabled). It is not a key in the AWF model alias table. When a workflow sets ANTHROPIC_MODEL=opusplan:

1. The gateway does not recognize opusplan as a known alias.
2. It falls through to the claude engine's resolution chain: ["agent", "sonnet-6x", "haiku", "any"].
3. None of the chain entries match Opus, so it eventually resolves via the catch-all any alias to whatever Anthropic model is available — in practice claude-sonnet-4-6.
4. No warning or error is emitted; the model substitution is silent.

Expected behavior

opusplan should be a recognized first-class alias in the AWF model table, mapping to Claude Opus with extended thinking enabled. For example:

"opusplan": ["copilot/*opus*", "anthropic/*opus*"]

…with whatever mechanism AWF uses to enable extended thinking on top of the resolved model. It should also be reachable from the claude engine chain so that ANTHROPIC_MODEL=opusplan has the intended effect.

Why this matters

opusplan is the standard Claude Code CLI alias for "use the most capable reasoning model with extended thinking". Workflows that set ANTHROPIC_MODEL=opusplan to invoke that capability silently get a Sonnet model instead when routing through a custom ANTHROPIC_BASE_URL backed by the AWF gateway. This makes the alias effectively broken in that setup.