oauth: skip OAuth validation when serviceAuths already authenticated request

[yjp20]

Problem

When an MCP server is configured with both the global OAuth provider (proxy.auth) and per-server serviceAuths, the middleware chain in internal/mcpfront.go:404-419 is built like this:

[mcpLogger, corsMiddleware, OAuthValidate, ServiceAuth, mcpRecover]

ChainMiddleware wraps last-wraps-first, so the actual execution order is:

mcpRecover -> ServiceAuth -> OAuthValidate -> corsMiddleware -> mcpLogger -> handler

A request with Authorization: Basic <creds matching serviceAuths> flows like this:

1. NewServiceAuthMiddleware matches the credentials, sets servicecontext.WithAuthInfo, calls next.ServeHTTP(...).
2. NewValidateTokenMiddleware runs next. It looks at the Authorization header, sees Basic instead of Bearer, and returns 401 with Invalid authorization header format and an RFC 9728 WWW-Authenticate: Bearer challenge — without consulting the service-auth context that ServiceAuth just set.

Net effect: configuring serviceAuths.basic on a server with global OAuth made Basic auth unauthenticatable, even when the credentials are correct. Same issue applies to serviceAuths.bearer tokens that aren't valid OAuth access tokens.

integration/basic_auth_test.go doesn't catch this because it passes nil for the auth config, so authServer == nil and OAuth middleware is never installed.

Fix

In NewValidateTokenMiddleware, short-circuit when service auth has already authenticated the request:

if _, ok := servicecontext.GetAuthInfo(ctx); ok {
    next.ServeHTTP(w, r)
    return
}

Symmetrically, OAuth-authenticated requests already pass through NewServiceAuthMiddleware cleanly via the existing oauth.GetUserFromContext check at the top of that middleware.

[gemini-code-assist]

Code Review

This pull request introduces a bypass in the OAuth validation middleware for requests already authenticated via service-specific credentials and includes integration tests for this behavior. However, the current middleware implementation may cause service authentication to block standard OAuth tokens if it precedes the validator in the chain. It is recommended to adjust the middleware logic and add a test case to validate that standard OAuth functionality is preserved in this configuration.

[dgellow]

Thanks young-jin! If you don't mind I will instead open another PR to fix the general issue of auth composition. That's what I see as the root cause here