fix: make TextMarshaler detection independent of the toolchain environment

[KT-Doan]

What

Make IsTextMarshaler independent of the toolchain environment by synthesizing the
encoding.TextMarshaler interface with go/types, instead of importing the real encoding
package through go/importer's default importer.

Why

IsTextMarshaler resolves encoding.TextMarshaler via importer.Default().Import("encoding").
The default importer locates stdlib export data by running go list -export against the GOROOT
the binary was built against. Whenever GOTOOLCHAIN selects a different toolchain at runtime — or
the binary simply runs on a machine whose Go installation lives at a different path than the build
machine's — that invocation fails with go: cannot find main module, the error is silently
swallowed, and every IsTextMarshaler check returns false.

The result is a silently wrong spec. A type that should render as type: string via its
MarshalText method (for example UUID types such as github.com/gofrs/uuid.UUID) instead degrades
to a $ref of its underlying [16]byte array. Swagger 2.0 forbids $ref for path parameters, so
the generated spec fails validation. Both call sites are affected — the schema TextMarshaler
shortcut and JSON map-key handling (IsJSONMapKey).

This reproduces with any GOTOOLCHAIN value that differs from the binary's baked GOROOT; it is not
tied to a specific Go release.

How

types.Implements matches method sets structurally, so a synthesized
interface{ MarshalText() (text []byte, err error) } is equivalent to the imported one. Building it
once with go/types removes the undocumented runtime dependency on a working go list entirely.
The change is behavior-preserving wherever the old code succeeded.

Tests

Adds TestIsTextMarshaler in internal/builders/resolvers, covering a type implementing
MarshalText() ([]byte, error) (and a pointer to it), a type without the method, a wrong-signature
MarshalText (no error result), and a builtin — verifying the synthesized interface matches
method sets precisely. The full suite, including the integration golden comparisons that exercise
TextMarshaler-backed types, passes unchanged, confirming the fix is a no-op wherever
importer.Default() previously succeeded.

[fredbi]

Interesting issue. And a difficult one to reproduce…
I am going to review that thoroughly.

@KT-Doan wouldn’t the same issue occur when detecting type time.Time? If the detected behavior is correct (i.e locations of stdlib at build time and scan time differ - which I need to ascertain first) any check against the stdlib could go wrong the same way. I am wondering thus if there isn’t a more general and safer way than emulating a synthetic type by constructing it from tokens.

[KT-Doan]

@fredbi Yeah it probably would affect when detecting time.Time as well.

It was a pain point for us causing a crazy amount of flakes when generating our SDKs in CI. The fix is in our own fork already just wanted to contribute it upstream.

[fredbi]

yeah I am trusting your judgement. I am trying to reproduce locally right now, to better understand the ramifications of the reported behavior. I can merge this week and push a patch release. Meanwhile I am trying to acquire a better understanding of how come the compiler would resolve the import at build time. Also looking for a simpler solution than building synthetic types (perhaps importing at runtime some fixed source code importing the local stdlib dependencies just for resolving the types and excluding this "fake" dep from the spec generation. Not sure yet.

At any rate, I really appreciate your feedback and i am always curious about how the community is using the tool.
Feel free to join on discord if you need support or want to share ideas or new directions: I've published a roadmap for this year and you guys at ORY definitely have a say.

[fredbi]

@KT-Doan ok behavior confirmed and reproduced locally. Good catch.
Further explorations:

• the blast radius of this bug is confined to this sole "special type" resolution (the bug is narrowed down to when we check for an interface - type identities like time.Time are not affected
• we can do slightly better than your by-the-token reconstruction: I am going to merge your fix then merge my "maintainability enhancement" - not a fan really of the prospect of having to maintain that specific part over the long run
• I'll add an additional CI harness for the lib that simulates the conditions you're describing, so we make sure we won't regress if adding someday another similar interface check

[fredbi]

Needs a more maintainable way of producing the synthetic interface.
Needs a test to reproduce the issue in CI.

I am taking care of these follow-ups.

Good catch. Good diagnosis. Thank you for contributing this.