MCPRemoteEndpoint CRD and MCPRemoteProxy Deprecation (RFC-0057)

[ChrisJBurns]

As a platform engineer managing remote MCP server backends,
I want a single MCPRemoteEndpoint CRD with explicit proxy and direct modes,
so that I can connect VirtualMCPServer to remote backends without unnecessary proxy pods for simple use cases, while retaining full auth middleware for backends that need it.

Size: XL
Dependencies: None (can run in parallel with other stories; STORY-07 sub-issue 07-C depends on this landing first)
Labels: operator, api, controller
RFC: RFC-0057

Context

VirtualMCPServer currently requires MCPRemoteProxy (which spawns thv-proxyrunner pods) to reach remote MCP servers. This forces OIDC auth on public remotes, creates dual auth boundary confusion, and wastes resources deploying pods just to make HTTP calls.

RFC-0057 introduces MCPRemoteEndpoint with two modes:

• type: proxy — Deploys a proxy pod with full auth middleware, authz policy, and audit logging. Functionally replaces MCPRemoteProxy.
• type: direct — No pod deployed; VirtualMCPServer connects directly to the remote URL.

MCPRemoteProxy is deprecated and receives no new features.

Scope

This story covers:

• Define MCPRemoteEndpoint CRD types with proxy/direct mode discriminator and CEL validation
• Implement controller for both modes (proxy mode creates infrastructure; direct mode is validation-only)
• VirtualMCPServer integration (discovering MCPRemoteEndpoint backends in both static and dynamic modes)
• MCPRemoteProxy deprecation (mark deprecated, no new features, document migration path)
• Helm chart CRD template and RBAC
• Unit and integration tests in cmd/thv-operator/test-integration/

This story does NOT cover:

• Removing MCPRemoteProxy (that's a future release)
• Config refs on MCPRemoteEndpoint (covered by STORY-07 sub-issue 07-C, which depends on this story)

Acceptance Criteria

• MCPRemoteEndpoint CRD defined with type: proxy and type: direct modes
• CEL validation enforces mode-specific field constraints (e.g., OIDC/telemetry rejected for type: direct)
• type: proxy controller creates Deployment, Service, and proxy pod (same behavior as MCPRemoteProxy)
• type: direct controller performs validation only — no infrastructure created
• Token exchange via externalAuthConfigRef supported for type: direct (tokenExchange type only)
• embeddedAuthServer and awsSts externalAuthConfig types rejected for type: direct
• VirtualMCPServer discovers MCPRemoteEndpoint backends (both static ConfigMap and dynamic runtime discovery)
• MCPRemoteProxy marked as deprecated in types, documentation, and Helm chart
• Migration guide from MCPRemoteProxy to MCPRemoteEndpoint (type: proxy)
• CRD manifest included in operator-crds Helm chart (deploy/charts/operator-crds/files/crds/)
• Printer columns: Mode, Phase, Remote URL, Age
• Unit and integration tests cover both modes, CEL validation, and VirtualMCPServer discovery
• All tests pass in CI (task test)

[ChrisJBurns]

Closing because this has been superseeded by #4656. We will deprecate MCPRemoteProxy later on and implement MCPRemoteEndpoint as part of v1beta2