fix(ipc): serialize concurrent execute() calls through a request queue

[belowzeroff]

Problem

The wire protocol carries no request id (ray_ipc_header_t is prefix/version/flags/endian/msgtype/size — see serde.h upstream): a RESP is correlated to a SYNC request purely by being the next thing to arrive on the socket after it was sent. That means at most one SYNC request may be outstanding at a time.

RayforceIpcClient.execute() didn't enforce that. It kept a single pendingResolve/pendingReject slot and wrote straight to the socket on every call, so a second concurrent call — a double Enter in the REPL input, a pagination click landing while refreshEnv() still has a request in flight — silently overwrote the first call's callbacks. Whichever response arrived first got handed to whichever caller happened to be last to call execute(), and every other caller just hung until its own timeout.

Fix

execute() now enqueues onto a FIFO requestQueue and calls pumpQueue(), which sends the next request only once the current one has fully settled (response, timeout, or write error — all funneled through finishCurrent()). finishCurrent() checks that the request it's asked to settle is still the current one, so a stale timeout firing after rejectAll() already cleared it (e.g. a disconnect mid-flight) is a no-op instead of a double-settle. disconnect() and the socket 'close' handler now drain the entire queue via rejectAll(), not just the one in-flight request, so anything still queued fails immediately instead of hanging on a dead socket until its own timeout.

executeAsync() is untouched — async messages never get a RESP, so they don't need to go through the queue and can still be fired at any time.

Testing

scripts/test-ipc.js gained a concurrency test: fire 10 execute() calls back-to-back without awaiting between them, then assert each one resolves to its own result. I confirmed this reproduces the bug against the pre-fix client — request #9's promise (the last call, whose closure ends up in the single slot) settles with request #0's result ((* 0 0) → 0n), and requests #0–8 hang until their 3s test timeout — and passes cleanly against the fix. Full suite: 33/33.