[FIX] 업무·하위 업무 담당자 자격을 등록·수정에서 검사하고, 후보 라벨에 운영진 역할을 싣는다 #709

📄 설명

업무·하위 업무의 담당자 자격을 서버가 등록·수정에서 검사하지 않는다. WorkServiceImpl·SubWorkServiceImpl은 담당자를 MemberService.findAssignableMember로만 본다. 이 메서드는 탈퇴·제명만 거른다. 후보 목록(GET /v1/members/assignable?authority=)에는 권한 필터가 있는데(#101) 단건 판정에는 없다. 그래서 화면이 거른 업무 담당자도 API·MCP로는 아무나 지정된다.

상위 이슈에서 정한 기준은 아래와 같다.

후보 목록 라벨도 함께 고친다. 지금 세 번째 칸은 «대표 역할, 없으면 등급»이다. 운영진 역할에 대표 표시가 없으면 등급이 찍히고, 대표 역할이 리더 역할이면 «트랙장»이 찍힌다. 응답에 표시용 역할명을 더해 운영진 역할을 먼저 싣는다.

✅ 작업 항목

• MemberService.findAssignableMember(memberId, requiredAuthority) — 목록판(findAssignableMembers)과 같은 규칙의 단건판. 판정은 AuthorityPolicy.hasAuthority 한 곳
• 업무 등록·수정이 WORK_MANAGE로, 하위 업무 등록·수정이 WORK_READ로 담당자를 본다. 회의 안건 승격(/promote·/promote-sub-work)은 등록 서비스를 부르므로 따라온다
• 수정은 담당자가 바뀔 때만 자격을 본다. 같은 담당자를 다시 보내면 판정 없이 그대로 둔다(탈퇴·제명 포함 — 웹 isAssignablePick이 이미 «현재 담당자는 후보에 없어도 그대로 저장»을 전제한다)
• 자격이 없으면 400. 이유가 «활동 회원이 아님»과 다르므로 코드를 나눈다(WORK_OWNER_NOT_ELIGIBLE · SUB_WORK_OWNER_NOT_ELIGIBLE · 코드 문자열은 기존처럼 VALIDATION_FAILED)
• AssignableMemberResponse.displayRoleName 추가. 고르는 순서는 ① 대표 역할이 운영진 역할이면 그것 ② 운영진 역할 중 표시 순번이 가장 앞선 것 ③ 대표 역할(리더 포함) ④ null. 운영진 역할은 LeaderRole이 아닌 역할이다. representativeRoleName은 그대로 둔다(lms가 읽는다)
• 시험: 업무·하위 업무 등록·수정의 자격 판정(없음 → 400 · 있음 → 통과 · 같은 담당자 재전송 → 통과) · 안건 승격 한 건 · displayRoleName 우선순위 · 기존 시험 픽스처의 담당자에게 권한 부여
• domain/operation/AGENTS.md·domain/member/AGENTS.md에 규칙 한 줄

🚫 검토했으나 택하지 않은 길

🔍 먼저 확인할 것

• 담당자를 지정해 업무·하위 업무를 만드는 기존 시험(서비스·컨트롤러·MCP·알림·감사 등 20여 개 파일)의 담당자가 권한 없는 회원이면 깨진다. 픽스처에 역할을 주는 방식이 클래스마다 다르다
• 쿼리 수를 못 박은 시험(WorkServiceImplTest 등)은 등록·수정이 아니라 조회를 센다 — 판정이 더하는 쿼리가 조회 숫자를 바꾸지 않는지 본다

🗄 배포 전 수동 DDL

없음

🙋🏻 참고 자료

• 상위: SoongSilComputingClub/ssccops#628
• [FIX] 운영관리 접근 권한 수정 #101(담당자 후보 authority 필터) · ADR-0067(리더 역할은 권한을 갖지 못한다)