requesthandler: Keep Parallel batch results in request order

[rdoupe]

A RequestBatch with executionType: 2 (Parallel) runs each request as its own thread-pool task, and each task appended its result when it finished (RequestBatchHandler.cpp line 217), so the results came back in completion order. WebSocketServer_Protocol.cpp (lines 336-339) labels results[i] with the requestType and requestId of requests[i], so a batch with a slow request first (a full-size GetSourceScreenshot) and quick ones after it returned every result under another request's label (upstream obsproject/obs-websocket#1317, reported by wesbos). Clients that match results by requestId read the wrong data.

The results vector now has one slot per request, each task writes its result at its request's index, and the batch waits for a finished count instead of the vector's size. Parallel results now come back in request order, as SerialRealtime and SerialFrame batches already do. The serial modes are unchanged.

Tested in obs-rust/obs-studio with test_ws_batch_order (3 of 5 fail before, 5 of 5 pass after, both libobs lanes), in a full OBS build (frontend + obs-websocket) in both lanes, and end to end over obs-websocket: the release returns 20 of 20 Parallel batches mislabelled, a build with this commit 0 of 20.

Refs obs-rust/obs-studio#813. The obs-rust/obs-studio PR that moves the submodule to this commit carries the regression test and closes the issue.

🤖 Generated with Claude Code

[zackees]

Reviewed the diff. Each Parallel task now writes to results[i] under the mutex and the batch waits on a finished count, so results line up with requests[i] as WebSocketServer_Protocol.cpp expects. Empty batch still returns at once (0 == 0), serial modes untouched, lambda captures i by value and request by reference into a vector that is not resized. The RED/GREEN evidence (test_ws_batch_order, 3 of 5 fail before, 5 of 5 after) lives in the obs-studio PR, which is still to come; the fork has no test lane beyond markdown lint.