mcp: tool schemas and metadata lose JSON number precision #1310

On upstream main at 7cb505c (Go 1.27.0, darwin/arm64), tools/list schema numbers and tool/result/content _meta numbers are rounded before the client receives them. structuredContent already preserves these numbers.

For example, register a tool with the low-level Server.AddTool API using this raw input/output schema:

{"type":"object","properties":{"id":{"const":9007199254740993}},"required":["id"]}

Return structuredContent: {"id":9007199254740993} and _meta: {"revision":9007199254740993}. After client/server transport, the schema constant and metadata revision re-marshal as 9007199254740992, while structured content still contains 9007199254740993. The same loss affects tool metadata, text content metadata, resource-link metadata, and embedded resource metadata. Negative large integers and high-precision decimals are also affected.

Expected: preserve numeric values in these arbitrary JSON fields at the protocol decode boundary, so consumers can use their original schemas and metadata. This is about descriptor/result fidelity, not implementing a new schema validator.

A regression reproduces this over both the SDK's serialized in-memory NDJSON transport and Streamable HTTP. It does not involve a downstream fork or custom transport decoder.

This differs from #1201 / #1244 / #1302, which address server-side applySchema, and from the explicit-null fix in #1285.

Proposed change: decode Tool and the CallToolResult wire object with the existing UnmarshalUseNumber helper. This keeps exported fields intact but changes decoded dynamic numeric types from float64 to json.Number for the affected fields. Callers asserting float64 need to adapt; maintainer agreement on this behavioral compatibility change is needed. No new compatibility switch or alternate value format is proposed. The current schema-validation dependency's precision limitations remain a separate concern.