Add Mcp-Method and Mcp-Name headers to HTTP requests

[EhsanAzish80]

Closes #228.

The HTTP client now sends Mcp-Method for JSON-RPC requests and notifications, plus Mcp-Name for tool calls, prompt reads, and resource reads. Names that cannot be sent safely as plain ASCII use the Base64 format from SEP-2243. Responses and legacy batches have no single method to mirror.

I added a transport test for each request type, notifications, responses, non-ASCII names, whitespace, and names that look like the Base64 marker. The new test failed before the change. After the change, swift test passed: 552 tests across 40 suites.

AI assistance helped prepare the implementation and tests.

[soyeladice-svg]

One value-encoding edge looks inconsistent with SEP-2243.

isSafeHTTPHeaderValue() permits horizontal tab anywhere except the first/last byte:

return bytes.allSatisfy { $0 == 0x09 || (0x20...0x7E).contains($0) }

But SEP-2243's MCP encoding rules are stricter than the generic HTTP field-value allowance: after the leading/trailing whitespace check, the plain representation must be ASCII 0x20...0x7E; any control character 0x00...0x1F or 0x7F must use the Base64 sentinel. That includes an interior HTAB.

So a name like "foo\tbar" is currently emitted raw instead of =?base64?...?=, which can also create mismatches with servers implementing the spec's decoder/validator literally.

Could isSafeHTTPHeaderValue require only 0x20...0x7E (with the existing leading/trailing-space sentinel handling), and add an interior-tab regression next to the newline/non-ASCII cases?

AI-assisted review; checked the current PR head against SEP-2243 value-encoding rules before posting.

[EhsanAzish80]

Fixed the tab encoding edge in bcc4d95 and added the regression. All 552 Swift tests passed locally. AI helped write the new test; I ran it. Could a maintainer review this and approve CI?