♻️ [Refactor] 멤버 조회 UseCase 2종 이식 (FetchMembersUseCase + FetchUserIdUseCase)

[jwon0523]

resolves #892

✨ PR 유형

♻️ [Refactor] — 레거시 AppProduct/ → UMCApp/(Tuist) ActivityDomain 모듈 이식

📷 스크린샷 or 영상(UI 변경 시)

🛠️ 작업내용

멤버 관리 도메인의 조회 UseCase 2종을 ActivityDomain 모듈로 이식했습니다.

• FetchMembersUseCase — MemberRepositoryProtocol(♻️ Refactor: 멤버 도메인 모델 + MemberRepositoryProtocol 이식 — v2 스펙 기준 #888) 단독 의존. 멤버 목록(전체/페이지) + 챌린저 상벌점 부여·삭제·이력 + 멤버 상세를 8-메서드 facade로 위임. 서버 식별자 전부 String 통일(레거시 Int → String).
• FetchUserIdUseCase — 현재 사용자 식별자 조회. 전용 CurrentUserIdProviding 인터페이스에 의존.
• 두 UseCase 모두 Swift Testing 단위 테스트(Mock 계약 검증, #if DEBUG 가드) 작성.

📋 추후 진행 상황

• MemberListViewModel / OperatorMemberDetailSheetViewModel 이식 (본 PR이 선행 기반).
• CurrentUserIdProviding Data 구현 시 AppStorageKey.memberIdString()(String) 사용 권장.
• (후속 정규화) FetchMembersUseCase가 조회 + 상벌점 mutation을 함께 노출 → read/write 분리 또는 MemberManagementUseCase 개명 검토.

📌 리뷰 포인트

• 책임 정규화 결정 (핵심): 이슈는 FetchUserIdUseCase가 MemberRepositoryProtocol에 의존한다고 전제했으나, 실제 레거시는 ActivityRepositoryProtocol.fetchCurrentUserId()(로컬 세션 read)에 의존. 멤버관리 repository에 current-user-id를 얹는 건 책임 불일치라, 머지된 ♻️ Refactor: 멤버 도메인 모델 + MemberRepositoryProtocol 이식 — v2 스펙 기준 #888 protocol 미수정 + 전용 CurrentUserIdProviding 분리. → 적절성 리뷰 부탁.
• …/Domain/Sources/UseCases/ — facade 위임 정확성 / String ID 통일.
• …/Domain/Sources/Interfaces/CurrentUserIdProviding.swift — seam 위치 + async throws 계약.
• …/Domain/Tests/UseCases/ — Mock 계약, 에러 전파 형제 대칭(파라미터화), #if DEBUG 범위.

✅ Checklist

• 커밋 메시지 컨벤션에 맞게 작성했습니다
  • 해당 링크 : 깃 모지 컨벤션
• 유지-보수를 위해 주석처리를 잘 작성하였는가?
  • 해당 링크 : Xcode 주석 정리