WebSocket reader data race in auto-PONG/CLOSE-echo handling in HTTP.jl

Summary

### Description

The WebSocket reader task processed incoming frames by calling `ws_on_incoming_data!` without holding `ws.sendlock`. That function is not a pure parser: its auto-PONG and CLOSE-echo paths `push!` onto the shared `ws.codec.outgoing_frames` vector, while application send/ping/pong/close paths mutate the same vector while holding `ws.sendlock`. Because the reader did not take the lock, a remote peer flooding `PING` frames against a multithreaded server (`julia -t N`, N>1) could drive concurrent `push!`/`empty!` of a Julia `Vector` from two OS threads — undefined behavior that can corrupt the array metadata or segfault the process.

### Impact

A remote peer could crash, or potentially corrupt memory in, a multithreaded WebSocket server through concurrent frame processing.

### Patches

Fixed in HTTP.jl v2.4.0. A new `_process_incoming_data!` helper acquires `ws.sendlock` and runs `ws_on_incoming_data!` followed by `_flush_ws_output_locked!` under the lock, making each decode atomic with its flush; all production decode call sites route through it. The blocking read stays outside the lock so concurrent senders cannot deadlock the reader, and lock ordering is unchanged.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.