[go] jsonrpc2 cleanup

[qmuntal]

This PR hardens the internal jsonrpc2 package:

• Replace the double-json.Unmarshal approach (try Request, then try Response) with a single decode into a combined wire struct which cleanly discriminates between requests and responses and validates the JSON-RPC version tag.
• Proper frame reader/writer
• Extract Content-Length framing into dedicated headerReader/headerWriter types with:
  • Clean EOF vs unexpected-EOF distinction (detects interrupted reads mid-header).
  • Proper strconv.ParseInt header parsing instead of fmt.Sscanf.
  • Validation of Content-Length > 0 and missing-header errors.
  • Graceful handling of unknown headers.
• Replace the mutex-guarded stdin.Write with a 1-buffered channel holding the headerWriter. This separates write serialization from the map-access mutex.
• Error.Data field changed from map[string]any to son.RawMessage to preserve exact wire JSON.
• Remove unused Notify method.

[Copilot]

Pull request overview

This PR hardens the Go SDK’s internal jsonrpc2 stdio transport by introducing dedicated Content-Length framing, simplifying message decoding, and standardizing error handling for JSON-RPC 2.0 interactions with the Copilot CLI.

Changes:

• Introduces headerReader/headerWriter for Content-Length framed IO and uses them in Client (plus channel-based write serialization).
• Replaces “try request then response” decoding with a single decodeMessage that validates the jsonrpc version and discriminates request vs response.
• Updates JSON-RPC error handling (standard error sentinels; Error.Data becomes json.RawMessage; removes unused Notify).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
go/internal/jsonrpc2/jsonrpc2.go	Switches to framed IO + unified decode path, updates error model, and removes Notify/write-mutex usage.
go/internal/jsonrpc2/frame.go	Adds Content-Length header framing reader/writer implementation.

[Copilot]

decodeMessage treats any object with a non-empty id and no method as a Response, but it doesn’t validate that a response contains either a result or an error (and not both). As a result, an invalid response with neither field would be accepted and Request() would treat it as a successful call returning a nil result. Consider rejecting responses where (Error == nil && len(Result) == 0) or where both Error and Result are present, and returning an ErrInvalidRequest-style error instead.