[Bug] MQTT duplicate clientId connections remain active and old-channel cleanup deletes the new session #7918

Behavior and reproduction

At fda742c48e7f553c9964cf74b36732326d0fde00, two accepted CONNECT packets with the same clientId can leave both channels active. If the old channel later disconnects, cleanup removes the replacement connection's session because it looks up session ownership only by clientId.

Executed with the real Connect handler, Disconnect.cleanChannel, repositories and two Netty EmbeddedChannels:

1. Connect old channel with clientId same-id and Clean Session true; consume its accepted CONNACK.
2. Connect a second channel with the same clientId and Clean Session true; consume its accepted CONNACK.
3. Observe both channels still active and the repository holding the replacement's session.
4. Run the old channel's normal cleanup routine.
5. Observe SessionRepository.get(same-id) becomes null while the replacement channel remains active.

No network broker or mocks were used for the connect/repository/cleanup behavior. Test channels were closed and their messages released afterward.

Location and cause

• Connect registers a channel without evicting another owner of the clientId
• ChannelRepository maps channel to clientId, with no active owner index
• Cleanup removes the session currently found by clientId

The server must disconnect the existing connection when accepting a new connection for the same client identity. Cleanup also needs an ownership check/fence so a stale channel cannot erase the replacement's session.

Impact / suggested repair

Reconnects can leave simultaneous active connections and then lose the active connection's session/subscription bookkeeping when the stale connection exits. Add an atomic clientId-to-active-channel ownership transition, close the replaced connection, and fence its cleanup against the new owner. Cover clean and persistent sessions, graceful and abrupt old-channel closure, and repeated reconnects.

Medium severity, high confidence from executed message handlers. Current issue/PR searches found no specific client takeover report; this is separate from wildcard matching, retained-message handling and Last Will publication itself.