### What happened?

Since #22311, `_get_allowed_mcp_servers_for_key` (and the team/end_user variants) union `mcp_tool_permissions.keys()` into the allowed-server set. This makes it impossible to revoke a server from a key while a `mcp_tool_permissions` entry for that server still exists — the tool-permission row silently re-grants the server.

The dashboard makes this worse: editing a key's MCP access and removing a server from `mcp_servers` leaves its `mcp_tool_permissions` entry behind, so the removal appears saved but has no effect.

### Current behavior

Key state observed on v1.92.0 (created and later edited via the dashboard):

```json { "mcp_servers": ["<opslevel_server_id>"], "mcp_tool_permissions": { "<opslevel_server_id>": ["..."], "<notion_server_id>": ["API-get-self", "..."], "... 9 more servers ...": ["..."] } } ```

Calling a Notion tool with this key **succeeds**, even though `mcp_servers` only grants the OpsLevel server. Effective access = union of both fields, so the widest field always wins.

This also interacts badly with `general_settings.require_key_mcp_access_defined: true`: the setting promises "keys see zero MCP servers unless their object_…