fix(audio-transform): serialize WebSocket writes to avoid concurrent-write panic

[Anai-Guo]

What

AudioTransformStreamEndpoint writes to the same Gorilla WebSocket connection from two goroutines:

• the backend-forwarding goroutine emits binary PCM frames (ws.WriteMessage) and can call sendWSError on a backend recv error;
• the read loop calls sendWSError for malformed mid-stream JSON or a backend send failure.

Gorilla WebSocket permits only one concurrent writer. These two writers race, which can panic with concurrent write to websocket connection and reset the active client session. A -race build reports the data race directly.

Fix

Wrap the connection in a lockedConn that serializes WriteMessage behind a mutex — the same pattern already used by the openresponses WebSocket endpoint (core/http/endpoints/openresponses/websocket.go). Reads stay on the single read loop, so only writes need the lock. All existing ws. call sites are unchanged because lockedConn embeds *websocket.Conn (promoting ReadMessage/SetReadLimit/Close) and overrides only WriteMessage.

Fixes #10844

Notes

AI-assisted, human reviewed.

🤖 Generated with Claude Code

[richiejp]

Thanks!

[localai-bot]

Reviewed this against issue #10844. Verification done:

• Audited every write site on the WS connection in audio_transform.go: the backend-forwarding goroutine's ws.WriteMessage (binary PCM) and sendWSError (called from both the read loop and the goroutine's recv-error path) are the only writers, and both now go through lockedConn.WriteMessage under the mutex. Changing sendWSError to take *lockedConn makes bypassing the wrapper a compile error.
• No WriteJSON/NextWriter/ping tickers in this endpoint; gorilla's implicit pong reply and Close use WriteControl/Close, which are documented safe to call concurrently with WriteMessage, so nothing escapes the lock.
• Mutex lives in the wrapper and is only ever used via pointer (no lock copying), and it is held only for the duration of a single write, so no deadlock risk. Reads stay on the single read loop as before.
• Pattern matches the existing lockedConn in core/http/endpoints/openresponses/websocket.go, so it is consistent with how the repo already solves this.

CI is green and the branch is mergeable. @mudler this looks good to merge: it serializes all WS writes exactly at the two racing sites from the issue, with a compile-enforced wrapper and no behavior change otherwise.