[BUG] Custom/unrecognized Anthropic model ID gets wrong capability info, sends thinking.type=enabled and gets rejected with 400

[grizmin]

Describe the bug

When using the Anthropic provider with a custom model ID that isn't a key in the built-in anthropicModels table (e.g. a custom deployment/proxy name for a Sonnet 5-class model), AnthropicHandler.getModel() looks up capabilities using anthropicModels[anthropicDefaultModelId] ("claude-sonnet-4-5"'s info) instead of the real underlying model's capabilities.

Since claude-sonnet-4-5 doesn't have supportsReasoningBinary, the request builds thinking: {type: "enabled", budget_tokens: N} (the legacy shape) instead of thinking: {type: "adaptive"}. Real Sonnet 5 / Opus 4.7+ class models reject the legacy shape:

400 {"type":"error","error":{"type":"invalid_request_error","message":"\"thinking.type.enabled\" is not supported for this model. Use \"thinking.type.adaptive\" and \"output_config.effort\" to control thinking behavior."}}

To Reproduce

1. Set API Provider to Anthropic with a custom base URL
2. Set Model to a custom deployment name that maps to a Sonnet 5 / Opus 4.7+ class model (e.g. claude-sonnet-5-bf)
3. Enable reasoning/extended thinking
4. Send any message

Expected behavior
Capabilities for an unrecognized model ID should be best-effort guessed from known model-family substrings (the same pattern already used in BedrockHandler.guessModelInfoFromId), so the correct thinking shape is used.

Related
This is the second half of the bug reported in #418 (same getModel() function). A single PR fixes both: #842