### What happened

A BYOK-enabled MCP server (`is_byok: true`) using a non-`oauth2` `auth_type` (e.g. `authorization`, `bearer_token`, `api_key`, `basic`, `token`) never surfaces its tools. The per-user credential is stored successfully (`has_user_credential: true`), but `tools/list` always returns empty for that server, and a subsequent `tools/call` by name fails with "Tool not found" — never even reaching the (correctly BYOK-aware) tool-call auth resolution.

### Why it matters

BYOK only actually works end-to-end for `auth_type: oauth2` servers. Any BYOK server configured with a simpler auth type (which is the natural choice when the upstream just wants a raw `Authorization`/`X-API-Key` header, e.g. Elastic's Kibana Agent Builder MCP, which requires `Authorization: ApiKey <key>`) silently never lists its tools for any user, making BYOK effectively non-functional outside the OAuth2 case.

### Root cause (traced in `v1.93.0`)

Two code paths resolve per-user MCP credentials, and they're inconsistently gated:

- **`MCPServerManager.call_tool`** (`litellm/proxy/_experimental/mcp_server/mcp_server_manager.py`, calls `_resolve_byok_mcp_auth_header`) — gated purely on `server.is_byok`.…