fix(core): report WebSocket bind failures instead of panicking

[cds-amal]

#774's CI run hit a WebSocket port race, but the bind failure surfaced as a misleading runtime panic:

parity_ws bind error
Cannot drop a runtime in a context where blocking is not allowed
Failed to receive WebSocket RPC server startup result

The port race is a separate issue. This PR fixes the failure path so a lost WebSocket port reports the bind error that caused it.

How

jsonrpc-ws-server creates a private Tokio runtime for its event loop and drops it when start() fails.

Our WebSocket starter called start() inside runtime.block_on. On a bind failure, that private runtime was therefore dropped from an async context, which panics. The handler thread died before it could publish the startup error, hiding the useful failure: which port failed to bind and why.

Fix

• Give the WebSocket server the executor already used by the pubsub tasks (event_loop_executor), eliminating its private runtime and worker threads.
• Share one server-thread scaffold between the HTTP and WebSocket starters instead of maintaining two copies of the same lifecycle logic.
• Publish a startup error on the handshake channel before emitting the aborted event (aborted delivery blocks under backpressure, and the caller waiting on the handshake may be the thread that drains events), and emit shutdown when a server exits abnormally.
• Close the already-running HTTP server when WebSocket startup fails instead of leaving its port bound.
• Make both starters plain functions; neither awaited anything.

Server behavior is otherwise unchanged: same servers, ports, and close handles.

How to test

The commits are ordered so both states reproduce. The regression test ws_bind_failure_reports_the_bind_error lands first: it occupies the WebSocket port and expects the bind error through the startup channel plus the aborted event. It is red at its own commit against the unfixed code, and the fix commit turns it green.

Baseline, from the PR branch (shows the CI failure pair: the runtime-drop panic and the masked channel error):

git checkout HEAD^
cargo test -p surfpool-core --lib ws_bind_failure_reports -- --nocapture

Fix (the bind error reaches the caller, no panic):

git checkout -
cargo test -p surfpool-core --lib ws_bind_failure_reports

• All 90 WebSocket integration tests pass on the shared executor.
• test_simnet_ticks passes end to end.
• Clippy clean on changed lines.

NOTE:

The port race itself remains: get_free_port binds :0, reads the assigned port, releases it, and hopes the port remains available; the runloop preflight check has the same time-of-check-time-of-use (TOCTOU) shape.

[greptile-apps]

Greptile Summary

The PR restructures HTTP and WebSocket server startup around a shared thread scaffold and ensures WebSocket bind failures reach the startup caller without a Tokio runtime-drop panic.

• Supplies the WebSocket server with an explicitly owned Tokio runtime and executor.
• Sends startup errors before potentially blocking aborted events.
• Closes the already-running HTTP server when WebSocket startup fails.
• Adds regression coverage for occupied WebSocket ports.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/core/src/runloops/mod.rs	The shared RPC startup scaffold correctly publishes handshake errors before blocking event delivery, resolving the previously reported deadlock path.

_{Reviews (4): Last reviewed commit: "docs(core): clean up docs" | Re-trigger Greptile}