Fix data race between Send and CloseSend operations

What does this MR do and why?

Problem

gitlab-org/quality/engineering-productivity/master-broken-incidents#14773 (closed)

There is a race between Send() and CloseSend() operations.

Race error:

WARNING: DATA RACE
Write at 0x00c003765a50 by goroutine 156:
  google.golang.org/grpc.(*clientStream).CloseSend()
      /root/go/pkg/mod/google.golang.org/grpc@v1.73.0/stream.go:999 +0x64
  github.com/grpc-ecosystem/go-grpc-prometheus.(*monitoredClientStream).CloseSend()
      <autogenerated>:1 +0x43
  github.com/grpc-ecosystem/go-grpc-middleware/tracing/opentracing.(*tracedClientStream).CloseSend()
      /root/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware@v1.4.0/tracing/opentracing/client_interceptors.go:81 +0x3a
  google.golang.org/grpc.(*GenericClientStream[gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/clients/gopb/contract.ClientEvent,gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/clients/gopb/contract.Action]).CloseSend()
      <autogenerated>:1 +0x43
  gitlab.com/gitlab-org/gitlab/workhorse/internal/ai_assist/duoworkflow.TestHandler.func3.Handler.3.3()

Solution

Use the same mutex to avoid the race.

References

Monday 2025-07-21 13:30 UTC - `gitlab-org/gitla... (gitlab-org/quality/engineering-productivity/master-broken-incidents#14773 - closed)

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.