fix: preserve data-URL-looking JSON strings

[bitbemol]

Fixes #277.

Preserves JSON strings decoded through Value as .string, including strings that match data-URL syntax. Explicit Value.data encoding and the data-URL helper APIs remain available, and the public API documentation now clarifies that parsing is opt-in.

Motivation and Context

Value.init(from:) currently interprets any parseable data-URL-looking JSON string as .data. Because generic JSON contains no discriminator between an ordinary string and an encoded Value.data, this can silently change both the Value case and the string's spelling.

For example:

Original: data:text/plain,Hello%20World
Decoded and re-encoded: data:text/plain;base64,SGVsbG8gV29ybGQ=

This can also affect content explicitly tagged as MCP text when it passes through generic Value conversion.

The change makes the string branch of Value.init(from:) always produce .string. Applications that intentionally accept data URLs can continue to opt in through Data.parseDataURL(_:), while explicitly constructed Value.data values retain their existing encoding.

How Has This Been Tested?

Added regression coverage for:

• Literal, base64-looking, empty, malformed, percent-encoded, non-ASCII, and application/octet-stream data-URL-looking strings
• Strings nested inside arrays and objects
• JSON string type and spelling preservation through round trips
• Explicit Value.data encoding
• The absence of an implicit .data discriminator on the generic JSON wire
• Typed MCP text content passing through Value erasure
• Typed image and audio content serialization

Verification performed:

• swift test --filter ValueTests: 8/8 tests passed
• Full Xcode test suite: 559/559 tests passed
• git diff --check: clean

The regression tests were also run against the previous decoder implementation to confirm that they reproduce the reported behavior.

Breaking Changes

This intentionally changes observable behavior for callers that relied on generic Value decoding to automatically convert data-URL-looking JSON strings into .data.

Those callers will need to explicitly call Data.parseDataURL(_:) in fields where data URLs are expected. Encoding an explicitly constructed Value.data remains unchanged, as does typed image and audio content serialization.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This behavior was encountered in bitbemol/second-brain-mcp, which currently vendors the patched SDK pending an upstream resolution.

This is my first contribution to swift-sdk. I may be missing context behind the original implicit decoding behavior and am happy to adjust the approach based on maintainer feedback.

AI assistance disclosure: This bug was initially identified with LLM assistance, and Codex assisted with implementation analysis and regression-test development. I personally reviewed the relevant SDK behavior, reproduced the failure in Xcode with the previous decoder, and verified the fix with the complete test suite.