openapi2conv: nil-guard components lookup in FromV3SchemaRef

[SAY-5]

What

Fixes #1062.

FromV3SchemaRef indexes components.Schemas[name] whenever the input schema has a $ref. Several recursive call sites in this file (FromV3RequestBodyFormData most notably) already pass components=nil when descending into array items and nested refs, so hitting a $ref from that path nil-dereferenced the components argument and took down the whole V3→V2 conversion.

In practice this fires on real-world inputs like the OpenAI OpenAPI 3.0 spec, where CreateEmbeddingRequest references a sub-schema inside an array of formData items:

FromV3SchemaRef (openapi2_conv.go:851)
FromV3RequestBodyFormData (openapi2_conv.go:1028)
fromV3RequestBodies (openapi2_conv.go:799)

Fix

Guard the components lookup with a components != nil check. When the components table is not available we fall through to the same 'return the plain $ref' branch that already handles non-binary schema refs - semantically 'the target schema is not known locally, emit a pass-through ref' - instead of panicking. Runtime behaviour for callers that do pass a non-nil Components is unchanged.

Verification

Locally on macOS, go 1.26.2:

• gofmt -s -l openapi2conv/openapi2_conv.go: clean
• go vet ./...: clean
• go test -race -count=1 ./openapi2conv/...: pass

Closes #1062

[fenollp]

LGTM but please add your spec (or a minified version of it) as a regression test.

[SAY-5]

@fenollp added TestIssue1062_FormDataArrayOfRefDoesNotPanic (openapi2conv/issue1062_test.go) — minified spec capturing the OpenAI shape: a multipart/form-data request body with an array property whose items $ref a component schema. Confirmed against the unfixed code (without this PR's nil-guard) it panics in FromV3 exactly as in the original stack frame; with the fix it converts cleanly and the resulting v2 spec carries the expected documents formData parameter.