Race in server.Consume between teardown and spawned goroutines

server.Consume spawns sender and Subscribe goroutines that write to returnError and read stopForLoop through heap-escaped pointers, but Consume returns without waiting for them. The goroutines outlive Consume, racing against its writes to returnError and its deferred close+nil of stopForLoop.

Concretely:

• multiple writers can land on returnError (the spawned goroutines plus the main path) with no synchronization;
• stopForLoop is closed and nil'd by Consume's defer while the goroutines may still be reading it.

Consume should wait for the spawned goroutines before returning, and stopForLoop should carry the error itself so the main path remains the sole writer of returnError.

Start at the server.Consume entry point and trace the spawned sender and Subscribe goroutines, focusing on their access to returnError and stopForLoop. Run the relevant Go tests with the race detector; done means Consume waits for those goroutines, the main path is the sole returnError writer, and teardown no longer races with goroutine reads.