feat: 저장소 멤버 관리 API 추가 (3단계)

저장소별 멤버 초대/역할변경/제거 엔드포인트를 추가한다.
- MemberService/MemberController: GET/POST/PATCH/DELETE /repos/:repoId/members
- 권한: 목록=멤버+, 변경=admin, 소유자(owner) 역할변경·제거 불가
- 초대는 가입된 사용자만(이메일 조회), 미가입/중복 시 BIZ_001
- InviteMemberDto/UpdateMemberDto, member.service.spec(가드 단위 테스트)
- 멤버는 Gitea 미동기화(조직 토큰 단일 모델), api-contract/진행현황 갱신

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/integration-progress.md

@@ -2,7 +2,7 @@
 
 > 프론트 UI(목업)를 NestJS 백엔드에 단계적으로 연동하는 작업의 진행 기록.
 > 계약/스키마 상세는 [`api-contract.md`](./api-contract.md) 참조.
-> 최종 갱신: 2026-06-16 · 현재 위치: **2단계(저장소) 완료 + Gitea 연동, 3단계(멤버) 대기**
+> 최종 갱신: 2026-06-16 · 현재 위치: **3단계(멤버) 백엔드 완료, 4단계(업무) 대기**
 
 ---
 
@@ -16,8 +16,8 @@
 ### 단계 순서
 
 ```
-0. 계약 정렬 ✅ → 1. 인증 ✅ → 2. 저장소 ✅
-→ 3. 멤버 → 4. 업무 → 5. 업무 상세 부속 → 6. 활동 피드 → 7. 내 업무 → 8. 마무리
+0. 계약 정렬 ✅ → 1. 인증 ✅ → 2. 저장소 ✅ (+ Gitea 연동 ✅) → 3. 멤버 ✅(백엔드)
+→ 4. 업무 → 5. 업무 상세 부속 → 6. 활동 피드 → 7. 내 업무 → 8. 마무리
 ```
 
 ---
@@ -77,15 +77,23 @@
 
 > **TODO(프론트)**: RepoSettingsPage/RepoDetailPage 에 `cloneUrl`/`htmlUrl` 표시(클론 주소 복사, Gitea 열기 버튼). 백엔드 응답에는 이미 포함.
 
+### 3단계 — 멤버 관리 ✅ (백엔드)
+
+**백엔드** `backend/src/modules/repo/`
+- `MemberService` + `MemberController`(repo 모듈에 흡수, `RepoMember` 엔티티 재사용). 엔드포인트: `GET/POST/PATCH/DELETE /repos/:repoId/members[/:userId]`.
+  - **목록**: 멤버이거나 공개 저장소만 조회(생성순 정렬). 응답 `RepoMemberResponse { user, email, subRole, taskCount, roleType, owner }`.
+  - **초대**: admin 권한. **이미 가입된 사용자만 이메일로 초대**(별도 초대 메일/계정 생성 없음). 미가입 이메일→`BIZ_001`(404), 이미 멤버→`BIZ_001`(409).
+  - **역할/직무 변경·제거**: admin 권한. **소유자(owner)는 역할 변경·제거 불가**(`BIZ_001` 403).
+- `InviteMemberDto`(email/roleType/subRole?), `UpdateMemberDto`(roleType?/subRole?). 단위 테스트 `member.service.spec.ts`(소유자 보호·중복·권한 가드).
+- `taskCount` 는 4단계 업무 모듈 도입 전까지 0.
+- **Gitea 미동기화**: 인증 모델이 조직 토큰 단일 사용이라 멤버↔Gitea collaborator 동기화는 하지 않음(사용자별 Gitea 계정 매핑은 8단계 후보).
+
+> **TODO(프론트)**: `useMember`/`member.store`, **RepoMembersPage**(초대 모달·역할 변경·제거) 연동.
+
 ---
 
 ## 3. 남은 단계
 
-### 3단계 — 멤버 관리
-- 백엔드: `GET/POST/PATCH/DELETE /repos/:repoId/members`(목록·초대·역할변경·제거), admin 권한 가드, owner 제거 불가.
-- 프론트: `useMember`/`member.store`, **RepoMembersPage**(초대 모달·역할 변경·제거) 연동.
-- `RepoMember` 엔티티는 2단계에서 이미 존재 → 데이터 계층은 일부 재사용.
-
 ### 4단계 — 업무(Task) CRUD + 상태 전이
 - 백엔드: `Task`(+`ChecklistItem`) 엔티티, `GET/POST/PATCH/DELETE /repos/:repoId/tasks[/:taskId]`, `POST .../status`. 상태 머신 todo→prog→review→done/changes.
 - 저장소 `doneCount/totalCount` 실제 집계로 교체(현재 0 하드코딩).
@@ -110,7 +118,7 @@
 
 ## 4. 전환기 한계 (현재 시점)
 
-- **RepoMembersPage·RepoActivityPage** 는 아직 mock `findRepo` 사용 → 실제 생성한 저장소의 **멤버/활동 탭은 "찾을 수 없음"** 표시(각각 3·6단계에서 해소).
+- **RepoMembersPage** 는 백엔드 API(3단계)는 준비됐으나 **프론트 연동 대기** → 연동 전까지 mock 사용. **RepoActivityPage** 는 아직 mock `findRepo` 사용(6단계에서 해소).
 - **RepoDetail 업무 목록**도 mock(4단계). 업무 모듈이 없어 모든 저장소 **진행률은 `0% / 시작 전`**.
 - `src/mock/relay.mock.ts` 는 아직 타입 정의(`Repo`/`User`/`TaskStatus` 등) + 미연동 화면 데이터 공급원으로 사용 중. 해당 도메인이 연동되면 데이터는 제거하고 타입만 `src/types/` 로 이전.