Diagnosing a Blocked Plugin Dependency Upgrade

A platform team's internal marketplace has two plugins: secrets-vault (an MCP server wrapping a secrets backend, currently tagged 2.1.0) and deploy-kit, whose plugin.json declares:

{
  "name": "deploy-kit",
  "version": "3.1.0",
  "dependencies": [
    { "name": "secrets-vault", "version": "~2.1.0" }
  ]
}

A different team's plugin, audit-tools, independently declares a dependency on secrets-vault with "version": "~3.0". An engineer who has deploy-kit installed tries to also install audit-tools.

1. What happens, and why?
2. Suppose instead audit-tools had declared secrets-vault with ">=2.1" (no upper bound). Would the same engineer's install succeed, and at what resolved version?
3. The secrets-vault team wants to disable the old 2.1.0 line entirely and force everyone onto 3.x. What two separate things do they need to be true before an engineer with deploy-kit installed can safely drop the ~2.1.0 constraint?