아카이빙 등록·수정·삭제·노출 변경 관리자 API 추가 #186

어떤 기능인가요?

추가하려는 기능에 대해 간결하게 설명해주세요

운영진 콘솔에서 아카이빙을 등록·수정·삭제하고, 슬랑제 페이지 노출 여부를 한 번에 바꾸는 관리자 API를 추가한다. 조회와 스키마 변경은 #185·#187에서 끝낸다.

• POST /v1/admin/archives — 등록
• PUT /v1/admin/archives/{archiveId} — 수정 (전체 필드를 받는다)
• DELETE /v1/admin/archives/{archiveId} — 삭제 (소프트 삭제)
• PATCH /v1/admin/archives/exposure — 슬랑제 페이지 노출 여부 일괄 변경

지금은 아카이빙을 넣을 방법이 DB 직접 수정뿐이다. #40이 학생 앱 조회만 만들었고 archive 도메인에 쓰기가 하나도 없다.

노출 변경은 목록의 체크박스 일괄 변경과 행별 드롭다운 변경에 같은 엔드포인트를 쓴다 — 행별 변경은 식별자가 하나인 요청이다. 하나라도 없는 아카이빙이 섞이면 아무것도 바꾸지 않는다.

📝 작업 상세 내용

• Archive에 쓰기 추가 — create, update, changeExposure
• ArchiveWriteCommand — 등록과 수정이 담는 값이 같아 하나로 둔다
• ArchiveRepository에 저장·삭제·일괄 변경 경로 추가
• AdminArchiveService에 네 동작 추가 (#185에서 만든 서비스에 얹는다)
• 등록·수정 — 사진 파일과 연결할 행사가 실제로 있는지 확인한다. 둘 다 다른 도메인이라 api:admin-api의 UseCase에서 조합
• 삭제 — is_deleted만 바꾼다
• 노출 여부 일괄 변경 — 하나라도 없으면 전체를 바꾸지 않는다
• ArchiveErrorCode 보강, @ApiErrorCode로 문서화

📁 참고 자료 (선택)

• API 명세: 관리자 페이지(노션)
• 관리자 화면 구현: https://github.com/kmu-yed/stream-admin
• 선행: 아카이빙 목록·상세 조회 API 추가 #40(학생 앱 조회) → 아카이빙 목록·상세 조회 관리자 API 추가 #185(관리자 조회·노출 여부·소프트 삭제) → 아카이빙 관련 링크를 행사 연결로 전환 #187(행사 연결 전환)
• 파일 존재 확인 선례: AdminNoticeWriteUseCase.requireFilesExist, AdminLockerPhotoUpdateUseCase
• 목록 전체 교체 선례: 사물함 구역 사진 수정(사물함 구역 배치·사진 수정 관리자 API 추가 #178)
• 다형 참조: notifications.target_id(V19), #187에서 만드는 ArchiveRelatedTargetType
• 식별자 목록 일괄 변경 선례: LockerStatusChangeRequest.distinctLockerIds, AdminLockerService.changeLockerStatus(사물함 상태 일괄 변경 관리자 API 추가 #146)
• 마이그레이션 없음. 아카이빙 목록·상세 조회 관리자 API 추가 #185·#187이 컬럼을 모두 넣는다

정한 것

• 연결할 행사는 relatedEventId 하나로 받는다. 생략하거나 null이면 "연결하지 않음"이고, 수정에서 null이면 연결을 끊는다(#187에서 정한 저장 모양 그대로)
• 연결할 행사가 실제로 있는지 확인한다. 없는 행사를 연결하면 상세에서 조용히 null이 되어 운영진이 눈치채지 못한다. 아직 게시하지 않은 행사는 연결할 수 있다 — 운영진 드롭다운이 그것도 보여준다
• 수정은 PUT으로 전체 필드를 받는다. 수정 요청이 등록과 같은 모양이고, imageFileIds가 빈 배열이면 사진 전체 삭제, relatedTarget이 null이면 연결 해제라 부분 수정이 아니다
• 대표 이미지는 요청에서 따로 받지 않는다. 대표는 사진 배열의 첫 장이므로 imageFileIds의 순서가 그 역할을 한다
• 노출 변경은 PATCH /exposure 하나로 받는다. 필드 이름도 isExposed다 — 아카이빙이 노출될 곳은 슬랑제 페이지뿐이라 식별자에 "슬랑제"를 넣지 않는다. 일괄 변경과 행별 변경이 같은 동작이고, 행별은 식별자가 하나인 요청이다
• 하나라도 없는 아카이빙이 섞이면 아무것도 바꾸지 않는다. #146의 사물함 상태 일괄 변경과 같은 기준이다
• 사진 파일·연결 대상 확인은 api:admin-api의 UseCase에서 한다. core:domain:event는 파일도 공지도 모르고, 행사는 같은 모듈이지만 서비스끼리 부르지 않는다(architecture.md 6-1절)
• 쓰기 응답에는 본문이 없다. 결과는 목록·상세를 다시 조회해 받는다
• 운영진 전용 동작은 AdminArchiveService에 둔다. 학생용 ArchiveService와 서로 호출하지 않는다

이 이슈에서 다루지 않는 것

• 아카이빙 목록·상세 조회, 노출 여부·소프트 삭제 컬럼 — 아카이빙 목록·상세 조회 관리자 API 추가 #185
• 행사 연결 스키마와 조회 — 아카이빙 관련 링크를 행사 연결로 전환 #187
• 슬랑제 전용 페이지의 공개 조회 API — 후속 이슈
• 파일 업로드 자체 — 기존 파일 API로 올린 뒤 식별자만 받는다
• 드롭다운에 채울 공지·행사 목록 조회 API — 공지는 AdminNoticeService에 이미 있고, 행사 관리자 목록은 #135에서 나온다