Deterministic sidecar IPC endpoint collides across hosts on the same workspace

ipc_path derives the sidecar endpoint purely from the sidecar name + workspace root hash (src/sidecar/manager.rs, ipc_path), so two editor windows on the same folder compute the same endpoint:

• Windows: the second sidecar's NamedPipeServerStream (maxNumberOfServerInstances: 1) throws ERROR_PIPE_BUSY; combined with the observability gap it exits 0 before READY — the #110 symptom for anyone using two windows. A zombie sidecar likewise occupies the pipe name forever; there is no analog of the Unix stale-socket cleanup (manager.rs unlinks stale sockets under #[cfg(unix)] only).
• Unix: worse but quieter — the second sidecar deletes and silently steals the live socket (IpcConnection.CreateUnixSocket stale-file delete), orphaning the first host's IPC.

Proposed: add a per-spawn unique suffix (PID or nonce) in ipc_path. Zero protocol change: the sidecar already echoes READY:<argv[1]> verbatim and the host re-parses the echoed path. Defense-in-depth: the Windows connect_transport should also retry on ERROR_PIPE_BUSY per the tokio named-pipe client docs (manager.rs connect_transport).

Spec refs: [DIST-CI-WIN-TRANSPORT]. Related: #110.

Start in src/sidecar/manager.rs with ipc_path and trace how the echoed READY path is parsed by the host. Then inspect connect_transport and the Unix stale-socket cleanup, using the issue's Windows and Unix collision scenarios as checks. Done means separate windows no longer share an endpoint and Windows connection attempts handle ERROR_PIPE_BUSY without changing the protocol.