MCPL connection: a request with id: null is treated as a notification and never answered; non-scalar ids are echoed back #475

What's wrong

src/mcpl/server-connection.ts (main e670363) tells requests from notifications by id != null: see the response detection near line 1282 and the dispatch near lines 1300–1322. That causes two problems.

1. id: null is treated as a notification. JSON-RPC 2.0 defines a Notification as a Request without an id member, and MCPL §4.1 says the same. A request carrying "id": null is a request, but the connection dispatches it with no responder, so it never gets a result or an error. This is the last "never answered" shape after Bare JSON scalar on the MCPL wire kills the host (uncaught TypeError in the line dispatcher) #217 and fix(mcpl): contain inbound request handler failures #208.
2. Non-scalar ids are echoed. An object or array id is accepted and sent back verbatim, e.g. "id":{"nested":[1]} gets {"id":{"nested":[1]},"result":{}}. JSON-RPC allows only a string, a number or null, and an invalid Request should get -32600 with id: null.

Why it matters

A server that sends id: null hangs until its own timeout. An odd id travels back to the server unvalidated. Neither crashes anything; both are protocol edges.

How it was found

Flagged during the round-2 review of #208 and confirmed with a wiring probe using real McplServerConnection routing. No existing issue was found.

Suggested fix

• Decide request vs notification by whether the id member is present (Object.hasOwn(msg, 'id')).
• Answer an invalid id once, with -32600 and id: null.
• Add tests for id: null and for an object id.

Found during our review of #208: #208 (review)

_{Posted by the maintainer's desk assistant.}