fix: handle untyped strict JSON responses - #2514

Greptile Summary

The PR replaces the earlier external-reference work with a focused strict JSON response fix.

• Classifies JSON body types according to whether Go permits them as method receivers.
• Wraps untyped, interface, and pointer response bodies while retaining direct response types for receiver-compatible declarations.
• Applies the representation consistently across standard, Fiber, and Iris strict templates.
• Adds generated cross-package fixtures covering reusable responses, headers, multipart callbacks, opaque named types, generics, and unsupported media.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains, and the previously reported external-reference issue is avoided because the focused replacement no longer changes externalref.go.

_{Reviews (2): Last reviewed commit: "test: cover strict JSON response receive..." | Re-trigger Greptile}

This also fixes #2525, which @mromaszewicz filed during review of #2522 (same bug as #1328). I was about to start on it and found this PR instead, so I took it for a spin rather than duplicate the work.

I merged the branch onto current main and generated strict-server code for every shape from #2525: schema: {}, type: "null", a 3.1 multi-type union, and a $ref to a named union component. Each one produces the Body wrapper and compiles, with the ref case classified by its underlying schema. Regenerating the committed fixtures on the merged tree produces no diff, so the output is consistent with the generator after #2522 and #2526.

Two non-blocking suggestions:

• The test specs are all OpenAPI 3.0.1. Since Map OpenAPI 3.1 multi-type unions to any #2522 merged, 3.1 multi-type unions and type: "null" also lower to any. The classification handles them, but a 3.1 fixture would pin that behavior against regressions.
• The new tests are compile-time checks (conversions and struct literals). A round-trip through a strict handler asserting the JSON on the wire would also catch visitor regressions, not just type-shape ones.

Neither should hold this up. The wrapper shape matches what #2525 proposes, and wrapping only receiver-incompatible bodies keeps the direct API for everything that compiles today.