fix: Validate JSONRPCResponse in constructor (fixes #605)

[vorburger]

Motivation and Context

Catch the root cause of #605 earlier if it ever happens again in the future.

How Has This Been Tested?

Not really, but hopefully it's safe; I would welcome code review!

Breaking Changes

Nope, this is an internal change for safety, which (hopefully) should have no impact.

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

@tzolov do you think this makes sense? I'm proposing this as a follow-up (NOT an alternative) to #607 (and #657), which IMHO makes sense either way as well.

[vorburger]

@Kehrlann @tzolov respectful friendly ping on this one?

[Kehrlann]

Hey @vorburger

Sorry it took us so long to get to this. The ID is not mandatory in Json RPC error responses (spec), so this could break parsing in valid cases.

I don't think users are supposed to create a JSONRPCResponse on their own, it's only done internally, either through direct object instantiation or through parsing with a guard (ref). So we have a good control on where this should happen, I don't think checking adds a lot of value.

If we wanted to do something like this, we'd rather do sub-types of JSONRPCReponse, but I don't think it would add a lot of value to the SDK, again, due to purely internal usage.