ipc transport: socket address uses ":" separator instead of Jupyter's "{ip}-{port}"

[paulk-asert]

When a Jupyter client launches a kernel with "transport": "ipc" (Unix domain sockets), the connection file's ip is a base path and each channel's socket path is {ip}-{port} — e.g. ip: "/tmp/kernel-abc", shell_port: 1 → ipc:///tmp/kernel-abc-1. That's what jupyter_client writes and what the frontend connects to.

JupyterSocket.formatAddress currently builds

return transport + "://" + ip + ":" + port;

which is correct for tcp but for ipc yields ipc:///tmp/kernel-abc:1, so the kernel binds sockets the client never connects to and the frontend hangs at "Connecting".

This has been masked until now because the released JeroMQ (0.6.0) emulates ipc:// over loopback TCP and can't interoperate with libzmq clients at all. JeroMQ master (zeromq/jeromq#998, merged Sep 2024, unreleased) implements real Unix-socket ipc on Java 16+; with that jar on the classpath the only remaining failure is this address format.

Reproduction (kernel built with JeroMQ master, Google Colab's public runtime image, jupyter_client 7.4.9):

KernelManager(kernel_name=..., transport='ipc', ip='/tmp/groovy-ipc-test').start_kernel()
# kernel creates:  /tmp/groovy-ipc-test:1 ... :5
# client connects: /tmp/groovy-ipc-test-1 ... -5   → "Kernel didn't respond in 40 seconds"
# after symlinking {ip}-{n} → {ip}:{n}:  kernel_info reply + execute OK

Why it matters: hosted Google Colab launches every kernel with --transport=ipc (it's why IJava/kotlin-jupyter/etc. all hang there, see googlecolab/colabtools#3267). With this fix plus a JeroMQ that supports Unix sockets, jjava-based kernels can run on Colab.

Fix: use - as the separator when transport is ipc. PR to follow.