Double auth transformation when MCPServer is behind VirtualMCPServer

Problem

When a VirtualMCPServer fronts an MCPServer that has externalAuthConfigRef (or authServerRef), auth transformations are applied twice:

1. The vMCP performs outgoing auth (token exchange, upstream inject, etc.) and sends an already-transformed token
2. The MCPServer's proxy applies the same transformation again via its own middleware

This affects tokenExchange and embeddedAuthServer type configs. Other types (headerInjection, upstreamInject, unauthenticated) are not affected because the MCPServer proxy either no-ops or defers to vMCP for those.

Root cause

externalAuthConfigRef on MCPServer serves two purposes:

1. Proxy middleware config — tells the MCPServer's proxy runner how to transform tokens (for standalone access)
2. Discovery metadata — tells the vMCP what auth strategy the backend needs (discovered mode)

These are conflated into one field. Both the vMCP and the MCPServer independently act on the same config.

Current workaround

Don't set externalAuthConfigRef on the MCPServer. Specify outgoing auth inline on the vMCP's spec.outgoingAuth.backends. The MCPServer's proxy passes tokens through without transformation. Downside: the MCPServer can't work standalone.

Proposed solution: authMode field

Add an authMode field to MCPServerSpec and MCPRemoteProxySpec:

// AuthMode controls whether this server applies its own auth transformation.
// - "self" (default): Server applies auth middleware from externalAuthConfigRef/authServerRef.
//   Use when the server is accessed directly by clients.
// - "external": Auth is handled by an external proxy (e.g., VirtualMCPServer).
//   externalAuthConfigRef is retained as discovery metadata only; no auth
//   middleware is added to the proxy. authServerRef is not started.
// +kubebuilder:validation:Enum=self;external
// +kubebuilder:default=self
// +optional
AuthMode string `json:"authMode,omitempty"`

Behavior

Files to change

CRD types:

• cmd/thv-operator/api/v1alpha1/mcpserver_types.go — add AuthMode field to MCPServerSpec
• cmd/thv-operator/api/v1alpha1/mcpremoteproxy_types.go — add AuthMode field to MCPRemoteProxySpec

RunConfig generation (the core fix):

• cmd/thv-operator/controllers/mcpserver_runconfig.go (~line 242) — gate AddExternalAuthConfigOptions and ValidateAndAddAuthServerRefOptions on authMode != "external"
• cmd/thv-operator/controllers/mcpremoteproxy_runconfig.go (~line 135) — same gate

Deployment generation (env vars, volumes):

• cmd/thv-operator/controllers/mcpserver_controller.go (~lines 1098, 1210) — gate GenerateTokenExchangeEnvVars, GenerateBearerTokenEnvVar, GenerateAuthServerConfig on authMode != "external"
• cmd/thv-operator/controllers/mcpremoteproxy_controller.go — equivalent gates

CRD generation:

• Run task operator-generate, task operator-manifests, task crdref-gen

Tests:

• Unit tests for RunConfig generation with authMode=external
• Integration tests verifying no middleware is added when authMode=external
• Existing tests continue passing (default authMode=self preserves current behavior)

Documentation:

• docs/operator/crd-api.md — document the new field
• docs/operator/virtualmcpserver-kubernetes-guide.md — guidance on when to use external

Backward compatibility

Default is self — existing resources behave identically. No CRD migration needed.

Start with the AuthMode fields in cmd/thv-operator/api/v1alpha1/mcpserver_types.go and mcpremoteproxy_types.go, then trace RunConfig and deployment generation in the listed controllers. Run the specified operator-generation tasks and add RunConfig and integration coverage for authMode=external. Done means external mode keeps discovery metadata but adds no auth middleware, auth server, environment variables, or volumes, while the default preserves existing behavior.