Allow for templated variable cascading scenarios across packages and remotes

[tadasant]

Follow on to #570

See #570 (comment) for the starting point

My rough understanding of what we want to accomplish here is to, at minimum:

1. Collect nested variables in the validators so that parametrized schemas like this are allowed:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-16/server.schema.json",
  "name": "io.github.SamYuan1990/i18n-agent-action",
  "description": "An i18n github action for language translate",
  "version": "mcp",
  "packages": [
    {
      "registryType": "oci",
      "registryBaseUrl": "https://ghcr.io",
      "identifier": "SamYuan1990/i18n-agent-action",
      "version": "mcp",
      "runtimeHint": "docker",
      "transport": {
        "type": "sse",
        "url": "https://example.com:{host_port}/sse"
      },
      "runtimeArguments": [
        {
          "description": "Port mapping from host to container",
          "value": "{host_port}:8080",
          "type": "named",
          "name": "-p",
          "variables": {
            "host_port": {
              "description": "The host (local) port",
              "isRequired": true,
              "format": "number",
              "default": "8080"
            }
          }
        }
      ]
    }
  ]
}

2. Properly document the scenarios where these template variables cascade (and what to do in case of conflicts / which layers have precedence).

(2) Might potentially deserve an extension to syntax to do things like {-p.host_port} or {p.host_port} in order to disambiguate more explicitly. But my inclination is to not add the extra syntax (just do blind {host_port} with some precedence order of where to look), as this won't be a commonly used feature and some reasonable precedence cascade would be sufficiently intuitive that users don't have to learn the syntax and can just intuit how variables would cascade.