feat: Expose invoke_mcp_tool through the ai-registry-tools (mcpgw) toolset

### Summary

The mcpgw MCP server exposes intelligent_tool_finder for discovering tools, but not invoke_mcp_tool for executing them. This issue asks whether exposing invoke_mcp_tool on that server is planned, or whether it was intentionally left off.

### Problem

mcpgw/server.py registers these @mcp.tool() functions:

- list_services
- list_agents
- list_skills
- get_skill_content
- search_registry
- intelligent_tool_finder
- healthcheck

invoke_mcp_tool is not among them, yet to my understanding the documentation (dynamic-tool-discovery.md) presents it as the natural execution half of the discovery workflow.

This leaves a gap for consumers of the ai-registry-tools toolset: the discovery step (intelligent_tool_finder) works out of the box as a server-side tool, but the execution step (invoke_mcp_tool) only exists as example agent-side code that each consumer must reimplement and wire up. So discover-then-invoke can't be completed through the toolset alone.

### Request

1. Is exposing invoke_mcp_tool as a first-class @mcp.tool() on the mcpgw / ai-registry-tools server planned, so discover → invoke works end-to-end through the toolset?
2. If it was intentionally left off, could you share the reasoning and the intended pattern for toolset consumers?

Start in `mcpgw/server.py`, where the `@mcp.tool()` handlers are defined, and confirm whether `invoke_mcp_tool` exists but is not currently exposed by the `ai-registry-tools` toolset. Then read `dynamic-tool-discovery.md` to verify the documented discover→invoke flow and expected behavior for consumers. Compare both to decide whether the tool should be added or whether a documented consumer-side pattern is intended. Done means the toolset either exposes execute capability or the docs clearly explain the intended handoff.

Written by the indexing model from the issue text.