[FIX] mcp: read the tool schema by its wire name

[beorngb]

Part of #190.

The gateway read the tool schema off the SDK's Python attribute
(tool.inputSchema), which is not part of any contract. mcp 2.0 renamed it to
input_schema; the list comprehension raised AttributeError for every server,
_connect reported "connection failed", and agents were served an empty tool
list.

model_dump(by_alias=True) returns the field under its protocol name, which
the MCP spec fixes and which both majors agree on — verified against 1.29.1 and
2.0.0, identical result. The gateway no longer cares which major is installed.

This does not make 2.0 work on its own. Scope of what remains, measured:

Client side	done here — one expression
plugins/ms365/server.py	1209 lines, 18 tools, decorator API
plugins/livekit-agent/server.py	359 lines, 4 tools, decorator API
tests/unit/mcp_gateway/echo_server.py	51 lines, trivial
Everything else	unaffected

Notes for whoever picks up the rest:

• The 166 inputSchema occurrences counted on Migrate to mcp 2.x (Tool.inputSchema renamed to input_schema) #190 are mostly a false
  positive. Almost all are plain dicts in the wire format or in the
  Anthropic/OpenAI/Gemini tool formats, and none of those change. gmail and
  google-workspace implement JSON-RPC by hand and never touch the SDK server.
• Tool(inputSchema=...) still constructs fine on 2.0 — the alias is
  accepted on input. Only attribute reads broke.
• The real server-side break is that @server.list_tools() / @server.call_tool()
  are gone and mcp.server.fastmcp was removed. The successor,
  mcp.server.mcpserver.MCPServer, derives schemas from function signatures and
  offers no way to pass an explicit JSON schema, so the 18 hand-written ms365
  schemas cannot move across mechanically. The lower-level
  Server.add_request_handler(method, params_type, handler) does allow keeping
  the current shape.
• No security pressure either way: OSV reports zero advisories for both 1.29.1
  and 2.0.0.