fix: add idle timeout and context cancellation to model stream reads

[aheritier]

Problem

A docker-agent run session hung permanently when a streaming LLM request to the model gateway stalled. The outbound TCP connection stayed ESTABLISHED but no data was flowing. Debug logs froze mid-request, CPU dropped to 0%, and SIGTERM was ignored — only SIGKILL worked.

Root cause (confirmed by code analysis):

The SSE stream-reading loop in handleStream blocked indefinitely in stream.Recv() → bufio.Scanner.Scan() → body.Read() → syscall.Read. There was no idle/read deadline and no explicit context-cancellation check between chunks, so:

1. A half-open TCP connection (remote side stopped sending data without closing) would park the goroutine forever.
2. SIGTERM (which cancels the root context) only helped if Go's net/http transport's readLoop goroutine happened to race ahead and call pc.close() before the body.Read blocked. Under scheduler contention or proxy configurations this race could be lost, making graceful shutdown unreliable.

Fix

pkg/runtime/streaming.go

• Idle timeout: stream.Recv() is moved into a dedicated reader goroutine. The main loop selects between the result channel, ctx.Done(), and a 5-minute idle timer. The timer resets on every received chunk. If no chunk arrives within the window the stream is declared stalled.
• cancelStream hook: on idle timeout, cancelStream(errStreamIdle) is called. This cancels the HTTP-request child context, which propagates to Go's net/http transport's readLoop; pc.close() closes the TCP socket and unblocks the goroutine that is stuck in body.Read().
• Context cancellation: the ctx.Done() select arm returns ctx.Err() immediately, making SIGTERM / Ctrl-C terminate the stream without racing against the transport.
• Goroutine cleanup: a done channel (closed via defer) signals the reader goroutine to exit on any return path, preventing leaks.

pkg/runtime/fallback.go

• Creates a context.WithCancelCause child context (streamCtx) for each stream attempt.
• Passes streamCtx to CreateChatCompletionStream and handleStream.
• The streamCancel function is the cancelStream hook described above.

Tests

Two new tests in pkg/runtime/streaming_test.go:

Test	What it verifies
TestHandleStream_IdleTimeout	A never-sending stream times out in 50 ms; errStreamIdle is returned; cancelStream is called
TestHandleStream_ContextCancellation	A never-sending stream is interrupted by context cancellation in 20 ms; context.Canceled is returned

Validation

• task build ✅
• task test ✅ (pre-existing TestLoadExamples/{dmr,unload_on_switch} failures confirmed unrelated)
• task lint ✅ (0 new golangci-lint issues; 2 pre-existing custom-linter warnings in unrelated files)

Closes #3209

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

[docker-agent]

[MEDIUM] Goroutine may persist briefly after handleStream returns due to undocumented Close()→Recv() contract

The reader goroutine relies on stream.Close() to unblock any in-progress stream.Recv() call. This works because the defer order is LIFO:

defer close(done)    // registered first → runs LAST
defer stream.Close() // registered second → runs FIRST

So stream.Close() fires before close(done). After stream.Close() unblocks stream.Recv(), the goroutine wakes up, enters the select, and may successfully send on recvCh (buffered, capacity 1) and loop back to call stream.Recv() again — before close(done) has fired. On a well-behaved stream implementation (where a closed stream's Recv() returns immediately), this is a benign extra iteration and the goroutine exits quickly.

However, if a chat.MessageStream implementation's Recv() can block even after Close() has been called (e.g., it returns from the first Recv() but then blocks on the second call after Close()), the goroutine will be stuck until ctx is cancelled. The done channel and ctx.Done() select arms only help once the goroutine has returned from stream.Recv(). There is no timeout or guarantee that stream.Recv() post-Close() will return promptly.

Suggested mitigation: Document the chat.MessageStream interface contract that Recv() must return promptly (immediately or with an error) after Close() is called. Alternatively, swap the defer order so close(done) fires before stream.Close(), giving the goroutine the best chance to notice done and exit cleanly before the stream is closed:

defer stream.Close() // register first → runs LAST
defer close(done)    // register second → runs FIRST (goroutine sees done closed)

With this order the goroutine sees done closed while still blocked in stream.Recv() (via the select after Recv returns), though it still needs stream.Close() to unblock the blocking Recv().