[BUG] localhost groupconnect (2 connections) broken on the beginning

[janbrothanek]

Describe the bug
Regression from v1.5.4, running srt-xtransmit with groupconnect (2 connections) on localhost usually stops with ALL LINKS BROKEN, ABANDONING, shortly after connecting.

To Reproduce
Steps to reproduce the behavior:

1. Build srt-xtransmit (734b5a97181f31543a73ac01f09de72cf8251f7c) with cmake .. -DENABLE_BONDING=ON, against srt v1.5.5 or current master 8e68635cf1075618dd8b47074f13503b54d8b740
2. Run ./srt-xtransmit receive "srt://:6000?groupconnect=1&mode=listener" "srt://:5000?groupconnect=1&mode=listener" --enable-metrics --reconnect
3. Run ./srt-xtransmit generate "srt://127.0.0.1:6000" "srt://127.0.0.1:5000" --enable-metrics --reconnect
4. Usually (not always though) the listener stops shortly after connecting with ALL LINKS BROKEN, ABANDONING.

Expected behavior
The listener should accept and keep receiving the traffic, reporting the metrics. That works as expected with v1.5.4.

Logs from listener

11:11:28.478820 [I] CONN Establishing connection no.1.
11:11:31.545186 [I] SOCKET::SRT_GROUP Accepted connection sock @1938964946. TSBPD Latency RCV 120ms, peer 120ms. KM state UNSECURED (RCV UNSECURED, SND UNSECURED). PB key length: 0. Cryptomode . Stream ID: not set.
11:11:31.545433 [I] [METRICS] @1938964946: Latency, us: avg n/a, min n/a, max n/a. Jitter: 0us. Delay Factor: 1us. Pkts: rcvd 0, reordered 0 (dist 0), lost 0, MD5 err 0, bad len 0.
11:11:31.811560/XTR:Rcv*E:SRT.gr: grp/recv: ALL LINKS BROKEN, ABANDONING.
11:11:31.811630 [W] RECEIVE read::recv: Connection does not exist
11:11:31.811650 [I] PIPE Pipe exit (conn @1938964946), 0 remain active.

** Logs from sender **

11:11:31.544161 [I] CONN Establishing connection no.1.
11:11:31.801826 [W] GENERATE socket::write::send: Connection was broken
11:11:31.801855 [I] PIPE Pipe exit (conn @1946301740), 0 remain active.

Desktop (please provide the following information):

• OS: Rocky Linux v9.8
• SRT Version / commit ID: v1.5.5 or current master 8e68635cf1075618dd8b47074f13503b54d8b740

Additional context
The bug seems to be in the listener, as it can be reproduced with listener built against v1.5.5 and caller built against v1.5.4 but not vice-versa.