### What happened?

For MCP servers defined in `config.yaml`, `_generate_stable_server_id` derives the server_id as:

```python params_string = f"{server_name}|{url}|{transport}|{auth_type or ''}|{alias or ''}" # sha256(...)[:32] ```

The docstring states the goal explicitly: the ID must be stable because "permission management is based on server_ids ... if the server_id changes across restarts, the key will no longer have access."

But the hash includes `url`, `transport`, `auth_type`, and `alias`. Editing **any** of those in config.yaml gives the server a brand-new ID on next deploy, which defeats the docstring's stated goal: every org/team/key `object_permission.mcp_servers` entry (and `mcp_tool_permissions` key) still holds the old hash.

The failure is completely silent: - `expand_permission_list` logs unresolvable entries at **debug** level and passes them through; the access check then denies. - The dashboard still shows the server as granted on keys/teams (the stale ID renders as if valid). - Callers get a plain 403 `"User not allowed to call this tool."` with no hint the grant is stale.

### Real-world impact

We changed `auth_type` on four config-defined servers in one re…