The MCP endpoint advertises the OIDC provider even when bearer tokens are not honored

DefaultMCPResource.hasOIDCProvider() decides whether to send the WWW-Authenticate: Bearer … resource_metadata=… challenge and whether to serve the RFC 9728 metadata document by checking that the OIDC provider's oidc resource handler component is registered, i.e. that the provider jar is installed. It does not check that the wiki's active authentication service is the OIDC token bridge (oidc-provider-bridge / TokenAuthService), which is what actually turns an Authorization: Bearer header into a wiki user. With the provider installed but the standard XWiki authenticator selected, a client is pointed at the provider, obtains a token, and is then refused on every call: since LLMAI-182 a request presenting credentials that fail to authenticate is answered 401, so the client loops on a challenge it has already satisfied. Reproduced 2026-10-04 on the local 17.10.8 instance (admin section → authentication service → Standard XWiki Authenticator; guest access off → 401 still carried the Bearer challenge).

Expected / proposal: Replace the "provider installed" test with "bearer tokens are honored on this wiki": resolve the active authentication service (research needed: the platform's authentication-service manager API and how the OIDC bridge identifies itself) and treat the endpoint as having no provider when the bridge is not active (bare 401, metadata 404). Show a warning in the MCP admin section when the provider is installed but not selected as the authentication service, so the admin sees the misconfiguration instead of the client. Keep the behaviour unchanged when the bridge is active.