[refactor/#698] 모임/알림 도메인 책임 분리 및 destination 기반 알림 V2 API 도입

[kanghana1]

❤️ 기능 설명

모임 도메인이 알림 서비스(NotificationCommandService)를 직접 호출하던 구조를 도메인 이벤트 기반으로 분리했습니다. 이 과정에서 알림 조회/리다이렉트를 알림 타입(type)이 아니라 destination(resourceType·resourceId·action) 기반으로 재설계한 V2 API를 도입했습니다.

기존 V1 API는 스펙을 그대로 유지한 채 @Deprecated 처리하고, V2로 생성된 알림에도 V1 호환 필드를 함께 저장하여 프론트의 V2 전환 기간 동안 무중단 호환을 보장합니다.

주요 변경사항

1. 모임 ↔ 알림 의존성 분리 (이벤트 기반)

• PartyCommandService가 NotificationCommandService를 직접 호출하던 구조를 제거하고 도메인 이벤트 발행으로 전환
  • PartyInfoChangedEvent / PartyDeletedEvent / PartyJoinRequestApprovedEvent / PartyRoleChangedEvent
  • 초대: PartyInvitationCreatedEvent / PartyInvitationAcceptedEvent
• PartyNotificationEventListener가 @TransactionalEventListener(AFTER_COMMIT) + @Async로 소비 → 알림 생성이 모임 트랜잭션과 분리됨
• 초대 상태(PartyInvitation)와 알림 상태의 생명주기 분리

2. destination 기반 V2 알림 API 추가

• GET /api/v2/notifications — 커서 페이지네이션 조회 (destination 포함)
• PATCH /api/v2/notifications/{id}/read — 읽음 처리 (초대 수락·거절은 초대 API로 분리)
• Notification에 resourceType·resourceId·action 컬럼 및 조회 인덱스 추가
• destination 규칙
  • 초대 요청 = PARTY_INVITATION + invitationId + RESPOND
  • 그 외 모임 알림 = PARTY + partyId + VIEW
  • 삭제 알림 = null

3. V1 API 하위호환 유지

• V1 조회/읽음 API의 요청·응답 스펙 무변경, @Deprecated(forRemoval)만 부착
• V2 알림 생성 시 레거시 필드(partyId, type, data)를 함께 저장(dual-write)하여 V1 API로도 정상 조회
• type 매핑은 기존 NotificationTarget의 defaultType과 1:1 동일 (INVITE→INVITE, 수정→CHANGE, 삭제·수락·역할→SIMPLE)
• 미읽음 여부 API는 그대로 유지

기대효과

• 모임 도메인과 알림 도메인의 결합도 감소, 이벤트 기반 확장성 확보
• 초대 상태(PartyInvitation)와 알림 상태의 생명주기 분리
• 알림 타입에 의존하지 않는 destination 기반 리다이렉트 지원
• 프론트 V2 전환 기간에도 기존 V1 클라이언트 무중단 호환

프론트에서 V2로 반영하면 추후 레거시코드는 삭제 예정입니다.

연결된 issue

연결된 issue를 자동으로 닫기 위해 아래 {이슈넘버}를 입력해주세요.

close #698 close #690

🩷 Approve 하기 전 확인해주세요!

✅ 체크리스트

• PR 제목 규칙 잘 지켰는가?
• 추가/수정사항을 설명하였는가?
• 테스트 결과 사진을 넣었는가?
• 이슈넘버를 적었는가?