fix: correlate invalid JSON-RPC envelope errors with the original request id

[anneheartrecord]

Fixes #2848

When an incoming message is valid JSON but fails JSON-RPC envelope validation (e.g. "jsonrpc": "1.0", a missing jsonrpc field, or a non-string method), the error response could not be correlated with the originating request:

• stdio: the server transport forwarded the exception in-stream and never answered, so the client got no response for its request id.
• Streamable HTTP: the server replied 400 with a JSON-RPC error using a null id ("server-error" on v1.x), breaking client-side request/response correlation.

This PR extracts the request id best-effort from the raw parsed payload (shared helper extract_raw_request_id; only spec-valid id types are accepted — strings and non-bool integers) and preserves it in the error response on both transports, falling back to a null id per the JSON-RPC 2.0 spec when no valid id can be extracted. The stdio transport now also answers unparseable lines with -32700 Parse error (null id), matching the HTTP transport's existing parse-error behavior. Envelope-invalid messages are now reported as -32600 Invalid Request instead of -32602 Invalid params, matching JSON-RPC 2.0 error code semantics (the issue's three repro cases are envelope violations, not parameter errors).

Tests cover all three repro cases from the issue on both transports, plus the null-id fallback (unextractable id and unparseable body). Full suite, ruff, and pyright pass.

[anneheartrecord]

For reviewers — summary to ease review:

Bug: when an incoming message is valid JSON but fails JSON-RPC envelope validation (e.g. "jsonrpc":"1.0", missing jsonrpc, non-string method), the error response couldn't be correlated to the request — stdio never answered at all; Streamable HTTP replied with a null id. (Issue #2848 has 3 repro cases.)

Fix: a shared extract_raw_request_id() helper pulls the id best-effort from the raw payload (only spec-valid id types — str / non-bool int), preserved in the error response on both transports, with null-id fallback per JSON-RPC 2.0 when no valid id exists.

Two deliberate calls worth a look:

1. stdio now also answers unparseable lines with -32700 Parse error (matching HTTP's existing behavior) instead of silently dropping.
2. Envelope-invalid messages now report -32600 Invalid Request instead of -32602 Invalid params (the repro cases are envelope violations, not param errors) — aligns with the codes touched in the recently-merged Fix unknown-method error code and add a protocol version registry #2836.

Both repro cases covered on both transports + null-id fallbacks. Full suite (1785), ruff, pyright all pass. If you'd rather land just the id-correlation core and split the stdio parse-error / error-code changes, I'm glad to narrow it.