test: end-to-end test with a Go-parity fixture #9

Part of #2. An end-to-end test of a generated server over real MCP and gRPC, the counterpart of Go's examples/gen/example/v1/e2e_test.go at 9e072f9. It adds a cross-implementation parity fixture.

Do

• Harness:
  • A fake VibeService tonic server that records the requests it receives. Run it in-process on 127.0.0.1:0 or over an in-memory channel.
  • The generated VibeServiceMcpServer in front of it.
  • An rmcp client connected over an in-memory transport (e.g. tokio::io::duplex).
  • Keep rmcp types inside the harness. The tests work on plain JSON from tools/list and tools/call, as Go's do.
• Port every Go e2e test:
  • TestToolsList, TestCallSetVibe, TestCallGetVibe, TestCallSetVibeDetails, TestCallSetVibeArray, TestCallSetVibeObjects
  • TestCallSetVibe_GRPCError, TestCallSetVibe_InvalidArgumentType, TestCallSetVibe_UnknownField
  • Keep the same inputs, and assert what the backend received and what the client got back.
• Parity fixture:
  • Commit examples/tests/parity/go-v0.3.0-tools.json: Go 0.3.0's tools/list result for the example service. Capture it by running Go's mcp-vibe at 9e072f9 (go run ./cmd/mcp-vibe and send initialize + tools/list over stdio), or by extracting Name, Description and InputSchema from its committed example_mcp.pb.go. Say in the PR which you did.
  • Assert the Rust server's tools/list is JSON-equal to it.
  • Also capture Go's tools/call result text for TestCallSetVibeDetails's input, and assert the Rust result is JSON-equal to it.

Acceptance criteria

• All ported e2e tests and both parity assertions pass in cargo test, with no network access beyond loopback.
• A mutation check described in the PR: break one schema rule in the generator, or one handler step, and show which test catches it.
• The checks in AGENTS.md pass.