[BUG] All client adapters fail to resolve MCP registry packages when registry_name is empty

[sergio-sisternes-epam]

Describe the bug

All three client adapters (VS Code, Copilot CLI, Codex) fail to install stdio-based MCP servers from the registry when the API returns an empty registry_name field for packages. The adapters match package types using package.get("registry_name") directly, which always fails with empty strings — resulting in either a misleading error or a misconfigured server entry.

To Reproduce

1. Run apm install with a dependency on a registry MCP server that only provides stdio packages (e.g. com.microsoft/azure)
2. APM detects packages exist ("Supported package types: npm, pypi, docker") but fails to map any of them
3. Package identifiers appear empty in output; the server is not correctly configured

Expected behavior

APM should correctly identify package types (npm, pypi, docker, etc.) and generate valid runtime configurations even when the registry API returns empty registry_name.

Environment

• OS: macOS / Linux / Windows (all affected)
• Python Version: 3.13
• APM Version: latest main

Observed registry API response

Querying the MCP registry API for the Azure MCP server (https://api.mcp.github.com/v0/servers/d3965c5a53be4f8bab7921b9d0511419) returns packages with empty registry_name for all entries:

{
  "packages": [
    {
      "name": "@azure/mcp",
      "version": "2.0.0-beta.24",
      "registry_name": "",
      "package_arguments": [
        {"type": "positional", "value": "server"},
        {"type": "positional", "value": "start"}
      ]
    },
    {
      "name": "msmcp-azure",
      "version": "2.0.0-beta.24",
      "registry_name": "",
      "package_arguments": [
        {"type": "positional", "value": "server"},
        {"type": "positional", "value": "start"}
      ]
    },
    {
      "name": "Azure.Mcp",
      "version": "2.0.0-beta.24",
      "registry_name": "",
      "package_arguments": []
    },
    {
      "name": "ghcr.io/azure/azure-mcp:latest",
      "version": "2.0.0-beta.24",
      "registry_name": "",
      "package_arguments": []
    }
  ]
}

This pattern is consistent across multiple servers in the registry — registry_name is empty for the majority of packages. The adapters' _select_best_package() and _format_server_config() methods rely on exact string matching against registry_name, causing all package type resolution to fail.

Additional context

• All three adapters are affected: vscode.py, copilot.py, codex.py
• The package_arguments field uses {type, value} format (e.g. {"type": "positional", "value": "server"}) which differs from the legacy runtime_arguments format ({is_required, value_hint})
• Package types can be reliably inferred from: runtime_hint (e.g. npx → npm, uvx → pypi) and package name patterns (e.g. @scope/name → npm, ghcr.io/… → docker)