Claude translated output schemas can falsely claim strict compatibility

[Ingwannu]

Summary

The Anthropic-to-Responses translation added in #5901 can emit strict: true for an incomplete object schema such as { "type": "object" }.

Reproduction

Send an Anthropic Messages request with:

{
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": { "type": "object" }
    }
  }
}

isAnthropicOutputSchema accepts this because its compatibility probe normalizes a clone. satisfiesOpenAiStrictSchema then sees no existing properties map to inspect, returns true, and formatFromOutputConfig forwards the unchanged schema with strict: true.

Impact

The translated Responses request claims strict compatibility but lacks the required object closure and required-field contract, so a conforming OpenAI Structured Outputs endpoint can reject it instead of applying the intended best-effort fallback.

Official OpenAI documentation requires the root to be an object, every object to use additionalProperties: false, and every declared field to be required. Unsupported composition must not be marked strict: https://developers.openai.com/api/docs/guides/structured-outputs#supported-schemas

Expected behavior

• Evaluate the original forwarded schema, not the normalized Anthropic acceptance clone.
• Emit strict: false for bare, open, malformed, optional-field, root-union, or unsupported-composition schemas.
• Preserve valid closed schemas, nested objects, arrays, definitions, and caller schema identity.
• Do not rewrite optional fields or silently close the caller's schema.

Regression coverage

Cover the helper, Anthropic inbound translation, and the parsed Responses request, including recursive nested schemas and literal/property names that resemble schema keywords.

[lidge-jun]

Fixed on dev by #6006, carried in #6059 (merge 8923ad9835).