fix: resolve OpenAPI spec $ref naming mismatch

DefaultOpenAPIV3Config pre-computes the Definitions map immediately
using the default GetDefinitionName (without ToRESTFriendlyName). The
kube-openapi builder (builder3/openapi.go) prefers the pre-computed
Definitions map over calling GetDefinitions again — so when main.go
overrides GetDefinitionName to add ToRESTFriendlyName, the schema
component keys get the friendly names but the $ref strings inside the
pre-computed map do not.

This caused the generated OpenAPI spec to have mismatched naming
conventions between $ref values and schema component keys, breaking
clients that rely on ref resolution (e.g. openapi-ts code generators).

Fix: nil out Definitions after overriding GetDefinitionName so the
builder falls through to GetDefinitions and builds fresh $refs using
the corrected GetDefinitionName, keeping both sides consistent.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: kevwilliams

cmd/search/main.go

@@ -190,6 +190,12 @@ func (o *SearchServerOptions) Config() (*searchapiserver.Config, error) {
 		friendlyName, extensions := namer.GetDefinitionName(name)
 		return openapiutil.ToRESTFriendlyName(friendlyName), extensions
 	}
+	// Nil out the pre-computed Definitions map so the OpenAPI builder re-invokes
+	// GetDefinitions with a fresh ref callback that uses the updated GetDefinitionName
+	// above. Without this, the builder uses the pre-computed $refs (which were built
+	// before GetDefinitionName was overridden) and the schema component keys diverge
+	// from the $ref values in the generated spec.
+	genericConfig.OpenAPIV3Config.Definitions = nil
 
 	// Configure OpenAPI v2
 	genericConfig.OpenAPIConfig = genericapiserver.DefaultOpenAPIConfig(openapi.GetOpenAPIDefinitionsWithUnstructured, namer)