Fix flaky TestNewCmdTaskInstantStop test

[stefanhaller]

TestNewCmdTaskInstantStop is flaky: it closes the stop channel from within start() and asserts the stopped task touched nothing. But Go's select picks uniformly at random among ready cases, so when opts.Stop and a data channel are both ready the loop can pick the data channel, call beforeStart() (which clears the view) and write the prefix before bailing. In production a task that's already been superseded thereby clobbers the output the incoming task is about to render.

Check stop with a non-blocking select before each blocking select, so the stop signal wins whenever it's already closed (Go has no built-in priority select; this is the idiomatic substitute). The selects keep their own stop case for liveness, to unblock when stop closes while parked waiting for data.