Public JSON ser/de helpers on the response types (following up on the invitation in #16)

[kittimzhe]

Following up on the invitation in #16: public JSON serialization/deserialization helpers on the answer and response types.

The gap: consumers who need JSON-able output currently have to either know the SDK is Pydantic-backed this release (model_dump()) or reach into the private _core.json module. Neither is documented. Anyone whose stack serializes SDK objects with another library (msgspec-based MCP stacks, structured logging, caching layers) hits this exactly where blakestone-x/jev-mcp did.

Suggestion: a documented to_json_dict() (naming TBD) on the answer/Schema types returning plain builtins, so callers never need to know which ser/de library backs the SDK. Optionally a from_json classmethod for symmetry.

One paragraph, one small API — happy to paste a patch sketch here if useful.

[aoright]

Drafted a patch on my fork adding to_json_dict(), to_json(), and from_json() via a small mixin inherited by Schema and the answer types.

All existing tests pass plus unit tests for dict and string roundtripping across NoulAnswer, ChoiceAnswer, ScoreAnswer, Usage, ModelMetadata, and SystemOneResponse.

Branch is here if anyone wants to review or test:
https://github.com/aoright/typesafe-sdk-python/tree/feat/response-json-methods

[kittimzhe]

Tested the branch against the consumer scenario that motivated this issue (the msgspec-based MCP stack from #16) plus round-trips — all green:

• The Answer objects are no longer msgspec-encodable after the v0.7 Pydantic migration, with no documented migration path #16 scenario: msgspec.to_builtins(answer.to_json_dict()) and msgspec.json.decode(answer.to_json()) both work cleanly on NoulAnswer/ChoiceAnswer/ScoreAnswer — this is the exact interop that used to raise TypeError: Encoding objects of type NoulAnswer is unsupported.
• Round-trips: ScoreAnswer with dict[int, ...] keys survives to_json_dict() → from_json() with keys back as int and equality holding — the strict=False on the dict path is what makes that work, since JSON turns the int keys into strings. ChoiceAnswer and a nested SystemOneResponse (answers dict included) round-trip both ways too.
• Tolerance/errors: from_json() on a dict with unknown fields is silently ignored, consistent with extra="ignore" wire behavior; malformed JSON raises a clean pydantic ValidationError.
• Suite: ran the full tests/ in a standalone venv — the 8 new json unit tests pass; my environment lacks some test-only deps (498 collection errors, identical on baseline 0.7.2), and the branch shows no regressions against that baseline (13 typing-drift failures vs 19 on baseline, all from my local checker versions).

One small suggestion: the strict=False in from_json() is load-bearing for the int-key round-trip above — a one-line note in its docstring would keep a future reader from "fixing" it into a round-trip break.

Thanks for picking this up — the mixin shape reads clean.

[aoright]

Good catch on the docstring note -- updated the from_json() docstring in commit c0a7b7a to document why strict=False is intentional for int-keyed dict coercion.