OpenAPI converter: pre-existing data-loss gaps in schema/example extraction

[h3xxit]

Surfaced during a cross-repo audit of the examples-parsing implementation. These are pre-existing gaps (they pre-date the examples work and also drop the schema, not just examples), so they were intentionally left out of the examples PRs and tracked here. All three cause silent data loss on spec-legal input. File: plugins/communication_protocols/http/src/utcp_http/openapi_converter.py.

1. OAS3 requestBody with a non-application/json media type drops the entire body

_extract_inputs hard-codes content.get("application/json", ...) with no fallback, unlike _extract_outputs which falls back to the first media type with a schema. A body declared only as application/xml, application/*+json, text/plain, etc. produces a tool with no body input at all.

"requestBody": { "content": { "application/xml": { "schema": {...}, "example": {...} } } }  // -> no body field

2. OAS3 parameter content form is ignored

A Parameter Object may carry its schema under content: {<media-type>: {schema, example, examples}} instead of schema. _extract_inputs only reads param.get("schema"), so the schema and examples are lost.

{ "name": "filter", "in": "query", "content": { "application/json": { "schema": {...}, "example": {...} } } }

3. OAS2 response examples sibling map is not read

In Swagger 2.0 the response example lives at responses.<code>.examples as { <mime>: <value> } (raw values, not Example Objects). _extract_outputs only reads responses.<code>.schema, so OAS2 response examples are dropped. Note this shape differs from the three forms _extract_examples handles and needs bespoke extraction.

Notes

• Same gaps exist in typescript-utcp (companion issue to be linked).
• Suggested fix order: (1) and (3) are the higher-impact; (2) needs parameter-content schema support generally.