Cross-process server-initiated peer/ping suite — the machinery
proof for ActionPeer (a backend initiating a JSON-RPC request to a
connected client and awaiting its typed reply). The sibling of the
one-way notification suite (role_grant_offer_notification_ws.ts),
extended from server→client *notifications* to server→client
*request/response*.
peer/ping is initiator: both: the client→server direction already
exists as heartbeat; the new server→client direction is what this
exercises. The observable trigger is the client invoking the peer/ping
action over its own socket — the handler turns around and *initiates*
a peer/ping request back to that socket, awaits the client's echo,
validates it against PingResponse, and returns the validated shape. So
one client RPC drives the whole round-trip, and every outcome
(success / Timeout / wrong-shape / client-error) surfaces as that RPC's
wire response — directly assertable.
The client side attaches an on_request responder at construction
(via create_ws_transport's seam) so the server-initiated request is
answered as soon as it arrives. Security negatives use the raw
WsClient.send to inject unsolicited / cross-connection frames.
Per-spec auth. peer/ping is auth: public (a liveness echo is
non-sensitive — see the design doc); the WS upgrade itself still
authenticates, so the suite drives it over the keeper's session.
Gated on capabilities.peer_request — true only for the Rust spine
(server-initiated requests landed Rust-first canonical); the TS family
skips until its server transport's request path lands (deferred twin-impl
convergence). Cross-process only: create_ws_transport needs a real bound
socket, so wire it from a *.cross.test.ts.