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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.