fix: mcp_service - don't drop the last response on backend EOF (#375)

[fer-marino]

Summary

Fixes #375.

HandleStreamPassThrough proxies JSON-RPC messages between a client-facing P2P stream and a backend MCP connection. It used to shut the whole thing down - s.Close() - the instant either leg reported any error, including the completely normal case of a one-shot HTTP-style backend answering one request and then closing its side (a clean EOF, not a failure).

network.Stream.Close's own documented contract:

Close may be asynchronous and does not guarantee receipt of the data... If acknowledgment is required, the caller must call CloseWrite, then wait on the stream for a response (or an EOF), then call Close().

The old code skipped exactly that: the backend-read goroutine would Write the response to the client, loop back, get EOF from the backend, and immediately trigger the deferred s.Close() a few instructions later - closing right behind a write that had already reported success. On the QUIC transport, Close() additionally cancels the read side over the wire (CancelRead sends a STOP_SENDING frame to the peer), which a plain TCP+yamux stream's CloseRead explicitly does not do (its doc says "Remote is not notified"). That's consistent with the original report: the producer's write reports success, but the response never fully reaches the consumer, which sees EOF instead.

Fix

The backend leg ending now only half-closes our write side to the client (s.CloseWrite()) and stops the backend->client relay goroutine; it no longer touches the read side or frees the stream. The client leg - the client itself finishing its read and hanging up, or a genuine transport error - is what triggers the final s.Close(). A 5s drain timeout (passThroughDrainTimeout) bounds the wait so a client that never hangs up can't leak the stream indefinitely.

Test plan

• Added TestHandleStreamPassThrough_BackendEOFDoesNotDropInFlightResponse in gate_test.go, which drives 50 real CallTool round trips over a real local QUIC connection between two SamNodes (a new startBareQUICNode helper - startBareNode's existing TCP+yamux transport can't exercise this: yamux's CloseRead is local-only per its own doc comment, so it structurally can't reproduce the wire-level race). It passes reliably with the fix.
• Being transparent about the test's limits: run against the pre-fix code, it did not reproduce the race on loopback across 1500+ iterations (with and without GOMAXPROCS=1), so it is not proof this fixes the exact wire-level interaction seen in the original report - only that the new code follows network.Stream's documented safe-shutdown sequence and behaves correctly across many round trips. Localhost loopback has effectively no latency/jitter, which likely closes the race window that a real multi-host deployment (or a relayed connection) would have. go build ./..., go vet ./..., and the full internal/node suite pass (the 6 pre-existing unrelated failures in that package are present identically on unmodified main).
• Maintainer confirmation against the original multi-host/production repro would be the strongest signal this actually closes out sam-node: tools/call succeeds on the backend but consumer sees EOF (producer->consumer relay drops the response) #375.

[gemini-code-assist]

Code Review

This pull request addresses a race condition where in-flight responses could be dropped when a backend closes its connection immediately after responding. It introduces a half-close mechanism on the client-facing stream, allowing the client to finish reading before the stream is fully closed, bounded by a 5-second timeout. A regression test using a real QUIC connection has also been added. Feedback suggests that if writing to the client fails, the error should be propagated to the main goroutine to avoid waiting for the timeout unnecessarily.