fix(amazon-bedrock): correct OpenAI catalog

[rekram1-node]

Summary

OpenAI-only split of #6637, based on current dev.

• Audit all 20 existing OpenAI Bedrock entries without changing their IDs or routes.
• Correct Safeguard reasoning metadata and complete its shared lab entry.
• Correct Runtime output limits and document the distinct Converse reasoning wire shapes.
• Replace inferred Astra citations with the published AWS card; retain upstream structured-output correction.
• Add India GPT-5.6 Luna/Terra and documented GovCloud GPT-OSS profiles.
• Convert open-weight provider entries to override-only base_model files.

Targeted Converse checks confirmed Safeguard reasoning, India profile invocation, Luna structured output and caching, Astra structured output, and GPT-OSS Runtime’s 128,000 output boundary.

Sources are in leading TOML comments, including AWS model cards and public pricing.

Validation

• bun validate
• git diff --check
• No model deletions or route changes

[github-actions]

Action items

• [high] [possible mistake] providers/amazon-bedrock/models/us-gov.openai.gpt-oss-120b-1:0.toml:15 - Check: Runtime/Converse GPT-OSS output limits after the documented 128k correction. Why: Commercial Converse entries (openai.gpt-oss-120b-1:0, openai.gpt-oss-20b-1:0) were raised to output = 128_000 with live maxTokens evidence, but the new GovCloud Converse twins keep output = 16_384 while citing the same AWS model cards. Same surface, divergent caps will understate GovCloud capacity. Action: Align GovCloud limit.output with the commercial Runtime 128k boundary, or document/verify a GovCloud-specific lower cap with card or live evidence (same for us-gov.openai.gpt-oss-20b-1:0.toml).
• [high] [possible mistake] providers/amazon-bedrock/models/openai.gpt-oss-safeguard-120b.toml:16 - Check: Runtime output-limit correction applied consistently across GPT-OSS Converse models. Why: Safeguard Runtime Converse still ships output = 16_384 while sibling GPT-OSS Runtime Converse was corrected to 128_000 on the same host/API family; the PR claims a Runtime 128k boundary but leaves Safeguard on the old value. Action: Set Safeguard Runtime limit.output to the verified Runtime ceiling (or prove Safeguard is capped at 16_384 on Bedrock) for both openai.gpt-oss-safeguard-120b.toml and openai.gpt-oss-safeguard-20b.toml.
• [medium] [possible mistake] providers/amazon-bedrock/models/openai.gpt-oss-120b.toml:15 - Check: Mantle GPT-OSS output limits vs the same AWS model-card sources. Why: Mantle openai.gpt-oss-120b.toml / openai.gpt-oss-20b.toml still use output = 16_384 while their Converse twins were corrected to 128_000 and Mantle comments point at the same model cards for “limits.” If Mantle shares that ceiling, the catalog still understates max output. Action: Verify Mantle max output against the card or a live Responses check; update to 128_000 if Mantle accepts it, or add an explicit Mantle-only limit note if 16_384 is real.

[rekram1-node]

Fixed in ccefa82 by correcting the earlier audit interpretation.

AWS’s current model cards explicitly document 16K max output for GPT-OSS 20B/120B and both Safeguards. The same GPT-OSS cards cover commercial Runtime, Mantle, and the exact GovCloud profile IDs. All eight entries now consistently use output = 16_384.

Targeted checks explain the prior confusion: commercial Converse rejects maxTokens beyond the 128K model/context boundary, while Safeguard Converse and Mantle Responses even accept request settings above 128K. Parameter acceptance therefore does not establish that the model can generate beyond AWS’s documented 16K output maximum. Comments on the commercial Runtime entries now state this distinction rather than presenting the request boundary as an output limit.

Sources:

• GPT-OSS 120B card
• GPT-OSS 20B card
• Safeguard 120B card
• Safeguard 20B card

bun validate and git diff --check pass.

[github-actions]

No actionable findings.