[FIX] 개인 채팅방 동시 생성 시 중복 방 및 참여 상태 불일치 해결

[Dimo-2562]

🛠️ 수정할 부분

개인 채팅방 생성/참여 및 첫 메시지 처리 흐름에서 동시성에 안전하지 않은 부분을 수정합니다.

배경

• 관련 PR: [feat/#625] 채팅 unread status WebSocket 이벤트 발행 #637
• 관련 이슈: [FEAT] 채팅 전송 시 안 읽은 메시지 이벤트를 웹소켓으로 발송하도록 구현 #625
• PR 리뷰에서 DirectChatRoomActivationService의 count == 1 기반 첫 메시지 판별이 동시 전송/동시 생성 상황에서 안전한지 질문이 있었습니다.
• 확인 결과, 해당 로직은 #637에서 새로 생긴 동작은 아니고 기존 ChatSendService의 첫 메시지 처리 로직을 분리한 것입니다.
• 다만 현재 direct room 생성 로직은 기존 방 조회 → 없으면 생성 구조라 A→B, B→A 요청이 동시에 들어오면 같은 사용자 쌍에 대해 개인 채팅방이 2개 생성될 수 있습니다.

현재 문제

• 같은 두 사용자가 동시에 개인 채팅방을 생성하면 중복 direct room이 생길 수 있습니다.
• 기존 방을 반환하는 경우에도 요청자의 ChatRoomMember 상태가 PENDING이면 JOINED로 전환되지 않을 수 있습니다.
• DirectChatRoomActivationService가 countByChatRoomId(chatRoomId) == 1 및 sender 제외 PENDING 멤버 기준으로 동작해, PENDING 사용자가 먼저 메시지를 보내는 경우 본인이 계속 PENDING으로 남을 수 있습니다.

수정 방향

• direct room을 (작은 memberId, 큰 memberId) pair로 정규화하고 DB unique 제약으로 중복 생성을 방지합니다.
• 개인 채팅방 생성 로직을 idempotent하게 변경합니다.
  • A→B와 B→A가 같은 방으로 수렴해야 합니다.
  • unique 충돌 발생 시 기존 방을 재조회해 반환합니다.
• 기존 direct room 반환 시 요청자의 membership이 PENDING이면 JOINED로 전환합니다.
• 첫 메시지 기반 PENDING 활성화 로직을 count == 1에 의존하지 않도록 개선합니다.
• 동시 생성/참여 상황에 대한 회귀 테스트를 추가합니다.

확인할 테스트 시나리오

• A→B, B→A 동시 생성 요청 후 direct room이 1개만 존재합니다.
• 반대 방향 요청도 같은 chatRoomId를 반환합니다.
• 기존 방 반환 시 요청자가 PENDING이면 JOINED가 됩니다.
• PENDING 사용자가 먼저 메시지를 보내도 PENDING으로 고착되지 않습니다.
• 기존 개인 채팅방 목록/검색 조회는 JOINED 기준 필터링을 유지합니다.