[Feat] 관리자 관광 지역 설정과 식당 지역 지정 API 추가

📌 이슈 종류

✨ 기능 추가 (Feature)

📝 작업 내용

지도 조회 API에는 관광 지역 모델과 집계 기능이 있지만, 관리자가 지역을 등록하고 식당의 소속 지역을 지정하는 경로가 아직 없습니다. 현재 상태에서는 실제 지역 데이터를 준비해도 API로 입력할 수 없어 초기 클러스터 화면을 완성할 수 없습니다.

기존 ADMIN 인증과 RestaurantPort를 사용해 지역 설정과 식당 소속을 관리합니다. 우선 API로 등록할 수 있게 만들고, 어드민 화면은 별도로 연결합니다.

✅ 체크리스트

관리자 관광 지역 목록 조회: 활성·비활성 지역, 코드, 이름, 대표 좌표, cameraBounds, 표시 순서
지역 코드 기준 생성·수정: 같은 요청을 반복해도 중복 지역이 생기지 않도록 처리
식당의 mapRegionId 지정·해제: null이면 미분류로 변경
입력 검증과 없는 지역·삭제된 식당 처리, 중복 생성 및 동시 수정 검증
admin → RestaurantPort → restaurant Service 구조 유지
관리자 API로 등록한 합성 데이터가 공개 지역 집계와 지도 조회에 반영되는 통합 테스트
실제 SecurityFilterChain의 ADMIN 허용 및 일반 사용자·비로그인 차단 테스트
Modularity 및 기존 식당 등록·수정 회귀 테스트

API

GET /api/v1/admin/map-regions
PUT /api/v1/admin/map-regions/{code}
PUT /api/v1/admin/restaurants/{restaurantId}/map-region

지역 코드는 안정적인 식별자로 유지하고 삭제 대신 비활성화합니다. 기존 map_region과 restaurant.map_region_id를 사용하며, 현재 검토한 범위에서는 새 dependency나 DB 컬럼이 필요하지 않습니다.

cameraBounds는 지역을 선택했을 때 보여줄 화면 범위입니다. 이 사각형을 관광 지역의 소속 경계로 해석하거나, 좌표만으로 소속을 자동 지정하지 않습니다. 식당 소속은 관리자가 명시적으로 지정하고, 화면 안에서 세는 식당 수는 기존 조회 계약을 따릅니다. 비활성화와 소속 변경이 기존 조회 세션에 미치는 영향도 확인합니다.

완료 기준과 실제 데이터 준비

서버 기능은 가상 지역·식당 데이터로 먼저 구현하고 검증할 수 있습니다. 운영 전에 기획이 승인한 지역 코드·이름·대표 좌표·화면 범위와 식당별 소속 데이터를 입력하고 실제 지도에서 확인해야 합니다. 승인되지 않은 대표 좌표나 식당 소속을 임의 seed로 추가하지 않습니다.

HASHI-PLAN main 1c981e5의 MAP_MAIN §4.1과 DEC-001은 초기 관광 지역과 대표 화면의 별도 설정을 요구합니다. 실제 좌표·화면 범위·식당 소속 목록은 문서에서 확인되지 않았습니다.