tests: Keep the WebSocket pending-read test pumping until its server closes

[madcodelife]

tests::network::websocket_pending_read_does_not_block_write_or_close fails intermittently in the GPUI Shell Components job (3 of the last 40 runs), with:

assertion `left == right` failed
  left: (true, true, false)
 right: (true, true, true)

The server saw the pong and the text, but not the close. This is a test race, not a product failure.

Why

The probe script only calls socket.close() after await socket.write(...) resolves, and that continuation runs on the test's main-thread executor. The test pumped the executor once after the server received the text, then blocked on server.join(). If the write had not resolved by then, nothing could run the close, so the server's 500 ms read timeout expired and it reported saw_close == false.

Fix

Use the same approach as #2875 for the sibling test: keep pumping the executor until the server thread has finished and the view shows write-and-close-finished, with a 10 s deadline. Then join the server and assert all three events. The text-received channel is no longer needed.

How to Test

cargo test -p gpui-shell --lib websocket_pending_read

Ran 240 times, 8 in parallel, locally on macOS: all passed. The original code also passed 240/240 locally, so the race could not be reproduced on this machine; the fix is based on the failure output and the ordering above.