Stdio transport for Snodo.Client.connect({:stdio, command, args}, opts).

A process owns a Port running command. It writes one JSON-RPC message per line to the server's stdin and reads newline-delimited messages from its stdout. The server's stderr is not captured. Responses are correlated by ID, so any number of processes can share one client and have requests in flight at once.

Options:

• :env - extra environment variables, as {name, value} string pairs. A nil value unsets the variable.
• :cd - the working directory for the command.
• :max_line_bytes - the largest response line to accept, default 16 MiB. The rest of a longer line is discarded as it arrives, so the request it answered times out; later responses are unaffected.
• :on_server_request - a function of one argument that answers a request the server sends to the client, as Snodo.Client.Transport describes. The connection process runs it in a linked process, one per request, and writes the response it returns; a function that raises is answered with -32603. Snodo.Client always supplies it, whatever the negotiated version. A caller that uses this transport directly without it gets -32601 for every server-to-client request.
• :max_server_requests - the most server-to-client requests whose handlers run at once, default 16. A request over the limit is answered with -32603 without running the handler.

The connection process monitors the process that called connect/2 and closes when it exits. An exit signal from another process, such as Process.exit(pid, :shutdown), stops it with that reason. When a request times out, the transport answers the caller with a -32001 error and sends the server notifications/cancelled for that request ID. When the server exits, or closes its stdin so that a write to it fails, requests in flight and later requests fail with -32000. notify/3 writes a notification and returns once the line is in the port. When the connection stops, through close/1 or the owner's exit, handlers still running for server-to-client requests are killed and their answers are not sent.

A notifications/progress whose token belongs to a request made with progress: is forwarded to the process waiting on that request, which calls the progress function; with reset_timeout_on_progress: true the connection process also restarts the request's timer. Other server notifications are dropped. If the progress function raises, the request is cancelled on the server.

A subscriptions/listen request opened with Snodo.Client.listen/3 shares the connection with ordinary requests. The connection process correlates the acknowledgement, the events, and the terminal response by the subscription ID (the request ID, carried in each notification's _meta["io.modelcontextprotocol/subscriptionId"]), delivers the events to the owner (see Snodo.Client.Subscription), and monitors the owner. Closing the subscription, or the owner's exit, sends notifications/cancelled for the request. When the server exits or closes its stdin, or close/1 stops the connection, open subscriptions end with a -32000 error.

close/1 closes the server's stdin. An MCP stdio server exits at EOF after finishing admitted requests; this transport does not signal or kill it.