Report unsupported external auth types - #6242

Thanks for digging into #5930 — the compatibility matrix itself is right. I checked every cell against the code rather than against the docs: the VirtualMCPServer and MCPServerEntry rows match the converter registry in pkg/vmcp/auth/converters/interface.go exactly, and the MCPServer/MCPRemoteProxy rows line up with the dispatcher switch in controllerutil/tokenexchange.go, including the non-obvious awsSts-on-MCPServer case, which fails on the empty-RemoteURL check in pkg/runner/middleware.go rather than silently no-opping. I also traced the reconcile flow to confirm it returns before the Deployment block, so this does close the unauthenticated-deploy footgun rather than just annotating it.

My main concern is scope. The issue asked for two things: reconcile-time validation surfaced as status conditions, and the supported consumer kinds documented in the field godoc. Both are here. But a lot came along with them, and some of it changes behaviour nobody asked to change.

The one I'd push back on hardest is the outgoing-auth precedence change in pkg/vmcp/aggregator/discoverer.go. In discovered mode an explicit per-backend override now wins over auth discovered from the backend resource, where previously discovered auth won. That decides which credential a live backend authenticates with. It may well be the right call, but it needs its own issue and its own discussion — it shouldn't be settled as a side effect of a PR about reporting unsupported types. Same goes for ExplicitBackends and its nil-versus-empty compatibility semantics, which exist only to support that change.

ExcludedBackends and DefaultAuthFailed are closer to the mark but still past the ask. The issue's vMCP line is "surface the skipped backend in VirtualMCPServer status rather than log-and-drop", which is a status condition. What's here is a fail-closed routing rework threaded through the discoverer, the watcher and the static path. I'd keep the condition and leave routing semantics for a separate change.

The examples fix (snake_case to camelCase under examples/operator/external-auth/) is a real bug and a good catch, but it's unrelated — worth its own PR so it can land quickly on its own merits.

Two things I'd treat as blocking regardless of what happens to the scope:

ensureVmcpConfigConfigMap now deep-copies the VirtualMCPServer, sets Spec.OutgoingAuth to nil, runs converter.Convert against that, then patches Source back on afterwards. That line is the only caller of Convert in the tree, so Converter.convertOutgoingAuth and convertBackendAuthConfig are now unreachable in production — they survive only in their own unit tests, which will keep passing while covering code that no longer runs. The controller already had a near-duplicate in convertBackendAuthConfigToVMCP, and this PR updates that copy to match the converter's behaviour. Better to pick one and delete the other than to disable the original by feeding it a modified input.

ExternalAuthConfigValidated on MCPServer has no path back to True. Both False branches are there (the new UnsupportedAuthType one and the pre-existing MultiUpstream one), plus RemoveStatusCondition when the ref goes away, but there's no success setter — MCPRemoteProxy has the matching block at the end of its handleExternalAuthConfig and MCPServer doesn't. Point a server at a two-upstream config, then edit that config down to one, and the condition stays False permanently. The MultiUpstream half predates this PR, but the new branch reproduces it in a function you're already editing.

Smaller things, several of which follow conventions already present in the files being changed:

• excludedBackends and explicitBackends need +listType=atomic. That's what's failing the CRD Schema Compatibility check, and there's an existing +listType=atomic about 200 lines up in pkg/vmcp/config/config.go. The other red checks aren't yours: the E2E lifecycle jobs all died on a Docker Hub 502 pulling python:3.9-slim, and the unit-test failure is a flaky transparent-proxy test unrelated to this change.
• pkg/vmcp/backendregistry/registry.go:130 still calls NewBackendWatcher without the auth config, and the comment directly above it asks that it stay in sync with cli/serve.go. It's only reachable from internal/exampleembedder today, but NewKubernetesBackendRegistry is the exported constructor for embedders and now has no way to pass an OutgoingAuthConfig at all.
• The "failed default means deny" rule is implemented three times: ResolveForBackend, dependsOnFailedDefault in the discoverer, and again inline in backend_reconciler.go. They agree today, nothing keeps them agreeing, and drift reopens the hole this is meant to close. Same for outgoingAuthExclusionSet, copy-pasted verbatim into two packages — it'd be better as a method on OutgoingAuthConfig.
• support_test.go re-declares supportMatrix as a literal and asserts Supports() matches it, so it can only fail on a typo made differently twice. The test that would earn its place asserts the vMCP rows equal the key set of converters.DefaultRegistry() and the MCPServer/MCPRemoteProxy rows equal the non-no-op arms of the dispatcher switch. That one breaks when someone adds a converter and forgets the table, which is the failure this package exists to prevent.
• Three new ...WithAuthConfig constructors for two production callers of the old ones. Changing the signatures is smaller.
• MCPRemoteProxy sets Ready=False with Reason: DeploymentNotReady for an external-auth configuration error.

One structural thought worth weighing before the next revision. The silent no-ops in AddExternalAuthConfigOptions are the actual subject of #5930 and they're still there — headerInjection, upstreamInject and xaa all still return nil. The support matrix is a second, hand-maintained source of truth sitting beside them, with nothing enforcing agreement. Making those arms return the UnsupportedTypeError directly would put the guard at the choke point every consumer already routes through, and the MCPServer/MCPRemoteProxy rows could then derive from the switch instead of restating it.