fix(bedrock): resolve context limits for every vendor prefix, not just anthropic

[ntdatt812]

What

getBedrockKnownModelLimits() normalizes a Bedrock model id before looking up
MODEL_SPECS:

const withoutProfilePrefix = unqualified.replace(/^(?:eu|us|global)\./i, "");
const withoutProviderPrefix = withoutProfilePrefix.replace(/^anthropic\./i, "");

The vendor peel is hardcoded to anthropic., so global.openai.gpt-5.6-sol is
only ever tried as openai.gpt-5.6-sol — which no spec matches. Every imported
openai.* model is stored with no inputTokenLimit, the pre-flight context
check falls back to the 200k default, and a 1M-context model is rejected locally
before the request reaches AWS:

[CONTEXT] Input exceeds context window for bedrock/global.openai.gpt-5.6-sol:
estimated 220940 input tokens, limit 200000.

This PR peels the two leading qualifiers a Bedrock id can carry (cross-region
profile, then vendor) and keeps the first candidate a spec knows.

Verifying the report first (#12915)

Measured on the tip through getBedrockKnownModelLimits():

model id	before	after
global.openai.gpt-5.6-sol	null	{inputTokenLimit: 1050000, outputTokenLimit: 128000}
global.openai.gpt-5.6-terra	null	{inputTokenLimit: 1050000, outputTokenLimit: 128000}
global.anthropic.claude-opus-4-6-v1	{1000000, 128000}	unchanged
us.anthropic.claude-sonnet-4-5-v1:0	{200000, 64000}	unchanged

So the report's root cause is confirmed, and its scope is wider than stated —
meta.*, amazon.*, mistral.*, deepseek.* hit the same gate.

One correction to the expected values. The report expects 1M; MODEL_SPECS
puts gpt-5.6-sol at 1_050_000, so that is what the import now stores. The
inputTokenLimit: null symptom is fixed either way.

What this does not fix. After the vendor gate is gone, coverage is whatever
MODEL_SPECS knows. I checked 14 non-anthropic ids (meta.llama4-maverick-…,
amazon.nova-pro-v1:0, cohere.command-r-plus-v1:0, mistral.mistral-large-…,
deepseek.r1-v1:0, qwen.*, ai21.*, writer.*, stability.*, twelvelabs.*,
luma.*): all still resolve to null, because no spec carries those names. They
are also unchanged from today's behaviour — none of them regress, and none of them
matched a wrong spec through the wider peel, which was the risk worth checking.
Populating those families is a catalog-data change, not this lookup.

Why the peel stops at two segments

A Bedrock model name contains dots of its own (gpt-5.6-sol), so splitting the
whole id and peeling greedily would eventually try 6-sol. An id carries at most
two leading qualifiers — <profile>.<vendor>.<model> — so the candidate list is
[id, unqualified, drop-1, drop-2] and the first spec hit wins.

Test

tests/unit/bedrock-vendor-context-limits-12915.test.ts drives
discoverBedrockNativeModels() with a stub fetcher returning a modelSummaries
payload — the real import entry point, not the lookup helper — and asserts the
openai.* model comes back with inputTokenLimit: 1_050_000 while the
anthropic.* model keeps 1_000_000. The two numbers differ, so a lookup that
answered with the neighbouring model's limit would fail both assertions.

Mutation

mutation	result
candidate list back to the anthropic.-only peel (shipped code)	✖ actual: undefined, expected: 1050000
drop ...(getBedrockKnownModelLimits(model.id) || {}) from withKnownBedrockLimits (the call site)	✖ actual: undefined

The second mutation is the point: the test fails when the wiring is removed,
not only when the helper's logic changes.

Regression

tests/unit/executor-bedrock.test.ts,
tests/unit/bedrock-image-log-redaction-7297.test.ts and the new file:
15 pass, 0 fail.

Closes #12915