golang-concurrencylisted

# Go Concurrency Prioritize correctness, bounded resource use, and understandable ownership. Concurrency is justified by a concrete need such as overlapping I/O, parallel computation, independent lifecycle work, or coordination—not by stylistic preference. ## Inspect before changing 1. Read repository instructions, `go.mod`, nearby synchronization conventions, tests, and shutdown wiring. 2. Trace each relevant goroutine from creation to completion: owner, inputs, outputs, cancellation, errors, panic behavior, and who waits. 3. Identify shared mutable state and the synchronization that establishes a happens-before relationship for every access. 4. Define expected concurrency, queue limits, overload behavior, ordering, and partial-result semantics. 5. Preserve existing lifecycle and API contracts unless the requested task requires changing them. ## Core invariants - Every spawned goroutine needs a defined owner and completion condition. Expose cancellation or waiting when the surrounding lifecycle must control or observe it. - Every channel needs a clear protocol: who sends, who receives, whether it closes, and who is allowed to close it. Usually the component that knows no more sends can occur closes it; receivers do not close merely to stop a sender. - A send of a pointer is not inherently unsafe. The real requirement is explicit ownership, immutability, confinement, or synchronization for the pointed-to data. - Add a cancellation case when a potentially blocking operati