Plugins can be marked 'required' by an organization and protected from being disabled or uninstalled

What

An organization can now mark a plugin as required via its marketplace/installation preference. Claude Code enforces this in several places:

• Attempting to disable a required plugin (or its synced counterpart) now fails with Plugin "<name>" is required by your organization and can't be disabled here. Contact your admin to change it. A related check also blocks disabling a plugin that other required plugins depend on, unless a bypassDependentsBlock option is passed.
• Uninstalling a plugin, and the "disable all enabled plugins" bulk action, now also skip org-required plugins (and anything they depend on), and report how many plugins were skipped as a result.
• The plugin details screen shows a new " · Required by your org" label next to a required plugin's enabled/disabled status.
• A new internal helper can force a plugin to be treated as enabled - bypassing user-disable and managed-disable checks - when it's marked required for its marketplace.
• Plugin enable/disable/uninstall failures now include a machine-readable failureCode field (e.g. not_installed_at_scope, settings_write_failed, already_in_goal_state, required_by_dependents, dependency_missing, dependency_disabled, dependency_policy_blocked, plugin_policy_blocked, ambiguous_marketplace, managed_name_locked, required_by_organization, builtin, not_installed, enabled_at_project_scope, partial_failure) alongside the existing human-readable message.

Why

This lets organizations lock in plugins they consider mandatory (for security, compliance, or workflow reasons) so users and scripts can't accidentally or deliberately turn them off, while giving tooling a stable code to key off instead of parsing free-text error messages.