Relay starts in a permanently broken IPC state when baton.sock is already in use

Describe the bug
If baton.sock is occupied, by a second relay instance or a stale socket, the IPC listener thread logs once and returns Ok(()) (relay/src/state.rs:373-380). It reports success while having done nothing. ipc_connect then sets ipc_thread_handle to Some regardless (relay/src/state.rs:495-497), so the guard at relay/src/state.rs:355-357 rejects every later Connect IPC press.

Because ipc_connect runs at startup (relay/src/main.rs:37-41), the relay boots straight into this state.

To Reproduce

1. Start one relay instance.
2. Start a second one.
3. The second shows :( No Baton Connection forever.
4. Press Connect IPC. Nothing happens and no error is shown.

Expected behavior
The socket conflict is surfaced in the GUI, and the thread does not report success when it failed to start.

Additional context
The only visible symptom is :( No Baton Connection, which is indistinguishable from the plugin simply not running. Disconnect IPC clears the handle and is the undocumented recovery. The message goes to stderr only.

Found while writing the setup documentation in #138 / #178.

Start with the IPC listener and connection flow in relay/src/state.rs:355-380 and 495-497, then trace the startup call in relay/src/main.rs:37-41. Reproduce the occupied baton.sock case with two relay instances and verify that startup surfaces the conflict, does not retain a successful thread handle, and allows a later Connect IPC attempt to recover.