golang-contextlisted

# Go Context Use `context.Context` to carry cancellation, deadlines, and request-scoped metadata across API boundaries. It is not a dependency container or a substitute for ordinary parameters. ## Inspect the lifecycle Before editing, trace the unit of work from its owner to every downstream call: - Where is the root context created? - Which caller owns cancellation and the deadline budget? - Which calls can block, spawn work, or cross a process boundary? - Does any child intentionally outlive its parent, and who owns that child? - Which values are genuinely request-scoped and cross-cutting? Read repository conventions and the minimum Go version in `go.mod`. Preserve established API contracts unless changing them is part of the request. ## API rules - Accept `ctx context.Context` as the first parameter of functions whose work can be cancelled or carries request metadata. Do not add context to pure, immediate helpers without a lifecycle need. - Pass the caller's context downstream rather than replacing it with `Background` in the middle of the call chain. - Do not pass `nil`; use a real parent or `context.TODO()` only as a visible temporary migration marker. - Prefer passing context per operation rather than storing it in a long-lived struct. A struct representing one operation may legitimately contain it when that API's documented lifecycle requires it. - Call a returned cancel function on every path once the derived context is no longer needed, unless ownership of can