[gmaclennan]

When a sync client sends a bad frame instead of a noise handshake (or the handshake fails for any other reason), the whole cloud process exits with code 1. Every other websocket connection and any in-flight REST download is dropped with it. An internal repro hit this repeatedly.

The /sync/:projectPublicId handler in src/routes.js discards the promise returned by wsCoreReplicator in src/ws-core-replicator.js, which is the node:stream/promises pipeline promise. When the replication stream errors that promise rejects with nobody listening, and node 20 treats an unhandled rejection as fatal.

This change catches the rejection in the route, logs it on the request logger at warn and terminates the offending socket if it is still open. It also adds a process-level unhandledRejection handler in src/server.js that logs at error and keeps the process running, so a future miss shows up in logs instead of taking the server down. The new test keeps sending garbage frames on the sync websocket until the server closes the socket, then checks that no unhandled rejection fired and that the server still answers GET /info. It has to keep sending because the handler awaits getProject before attaching the pipeline, and a frame that arrives before then is dropped; that early-frame gap is pre-existing and worth a separate issue.

One question for reviewers: is warn the right level for a per-connection replication failure? Garbage from one client is not a server fault, so info may be enough, but warn makes repeated failures from a misbehaving client easier to spot.