MCP server allowlist policy can now be inherited from lower-priority admin settings, with a warning when it's shadowed

What

Organizations can control which MCP (Model Context Protocol) servers Claude Code is allowed to use through settings like allowManagedMcpServersOnly and allowedMcpServers. Previously these were read from a single merged settings object. Now:

• Claude Code computes these values by combining the highest-priority settings source (the "slot") with the list of admin policy tiers, so a policy set only in a lower-priority admin settings source can still take effect even if there's no explicit override in the higher-priority one.
• If the top-priority settings slot doesn't explicitly set allowManagedMcpServersOnly to false, Claude Code now falls back to an allowlist derived from the admin tiers rather than ignoring it.
• A new startup warning lists any MCP-related policy keys that are set in a lower-precedence managed settings source and are therefore not being applied, and points admins to the /status command to see which keys are affected.

Why

Before this change, an MCP allowlist or lock configured only in a lower-priority admin settings file could be silently ignored if it wasn't also set at the top level, leaving organizations less protected than intended. Now the policy is inherited correctly, and when a setting is still being shadowed by a higher-priority source, admins get a clear warning instead of a silent gap.