[EhsanAzish80]

Closes #228. The HTTP client sends Mcp-Method for JSON-RPC requests and notifications, plus Mcp-Name for tool calls, prompt reads, and resource reads. Names that are not safe as plain ASCII use the Base64 format from SEP-2243. Responses and legacy batches have no single method to mirror.

The branch is updated to current main and includes the Ubuntu CI setup and client-test timing fixes shared with #307.

Tests: request types, notifications, responses, non-ASCII names, whitespace, and Base64-marker names passed locally before this update. All six CI jobs passed on 4a58c34, including Ubuntu tests. AI helped write the tests; I ran them.

[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?