fix(protoc-gen-openapiv2): fix panic on enum resolution in nested messages

[franchb]

Summary

Fixes #6366 — protoc-gen-openapiv2 panics with "can't resolve OpenAPI ref from typename" when messages reference enums or cross-package types (regression from #6315).

Three bugs in collectReferencedNamesForCache():

1. Traversal order: Message FQMNs were pre-populated in the refs map before scanning services. Since collectNestedTypeFQNs uses refs for cycle detection, it short-circuited on pre-populated entries and never discovered nested enum types. Fixed by moving message pre-population to after service scanning.

2. Incomplete traversal: Only service method request/response types were traversed for nested types, but renderMessagesAsDefinition renders all messages from the file. Cross-package types referenced by non-service messages were missing from the naming cache. Fixed by also calling collectNestedTypeFQNs on all messages from the current file.

3. Package filter: The filter compared only the first dot-component (e.g. "example") against the full multi-component package name (e.g. "example.v1"), which always failed. Fixed by using strings.HasPrefix(trimmedName, currentPackage+".").

Test plan

• New test TestGenerateEnumInNestedMessageMultiComponentPackage — models the exact reproducer from the issue (single file, multi-component package, nested enum)
• New test TestGenerateCrossPackageMessageReference — tests cross-package message references (different proto packages)
• TestGenerateMultiFileNamingConsistency — no regression on $ref and definition name mismatch for google.rpc.Status when processing multiple proto files with nested Status type #6308
• TestGenerateMergeFilesWithBodyAndPathParams — no regression on protoc-gen-openapiv2 panics when generating OpenAPI for services with messages in separate files (Protobuf Edition 2023) #6274
• Full go test ./protoc-gen-openapiv2/internal/genopenapi/... passes
• Verified fix against a real-world project with multiple proto files across packages

🤖 Generated with Claude Code

[johanbrandhorst]

This looks.. reasonable? This code is pretty hard to follow, but if this fixes the case supplied in the bug then I'm satisfied.

[johanbrandhorst]

@printfn any chance you could pull this and try it out in your environment to confirm the fix?

[printfn]

The fix seems to work. I did notice that compared to 2.27.7 a bunch of the "$ref" values in the generated JSON seem to have changed. I assume this is expected?

[johanbrandhorst]

The fix seems to work. I did notice that compared to 2.27.7 a bunch of the "$ref" values in the generated JSON seem to have changed. I assume this is expected?

Hm, perhaps if you're using the opaque API? I'm not sure, but if they break anything please open a new issue. I'll merge this and get a release out with the fix, thanks!