Don't cancel run context on stdin EOF

[llogen]

The send goroutine's defer cancel() caused the receive goroutine to be killed immediately when stdin was /dev/null (e.g. when run non-interactively), resulting in no output being printed. Only the receive goroutine should drive termination.

[Copilot]

Pull request overview

This PR fixes dutctl run streaming RPC lifecycle so that stdin reaching EOF (e.g., non-interactive /dev/null) does not prematurely terminate the RPC receive path, ensuring server output is still printed.

Changes:

• Introduce a recvDone signal to let the receive goroutine drive overall termination.
• Remove cancel() from the send goroutine teardown to prevent stdin EOF from cancelling the run context.
• Update the final wait/termination select to wait on receive completion instead of runCtx.Done().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Now that stdin EOF no longer cancels the context (good), the send routine still exits on io.EOF without half-closing the client->server request stream. Server-side code treats client stream closure (io.EOF on Receive) as the signal that no more requests are coming; consider explicitly closing the request side (e.g., stream.CloseRequest()/equivalent for connect.BidiStreamForClient) when stdin reaches EOF so the server can stop waiting for further client messages without relying on full context cancellation.

[Copilot]

recvDone is closed unconditionally in the receive goroutine, including when that goroutine hits a non-EOF error and sends it on errChan. In that situation both recvDone and errChan can become ready, and the final select may pick recvDone and return nil, silently dropping the receive error (same for a send error racing with receive completion). Consider making the completion signal carry an error (e.g., recvDone chan error) or, at minimum, ensure the recvDone path checks/drains errChan before returning nil so real worker errors can’t be lost.

Suggested change

	case <-recvDone:
	case <-recvDone:
	// Prefer any pending worker error over a silent success.
	select {
	case err := <-errChan:
	if err != nil {
	return err
	}
	default:
	}

[jenstopp]

The context is:
Triggering the dutctl client binary inside another framework, right? Although this should also work, of course, it is not the intended use: the client is for humans, and the RPC API (of the agent) is for systems.

Thus, I need to take a closer look, as this change touches a critical part of goroutine synchronization and cannot pull it in quickly.