refactor: core 에 섞여 있던 조합·도메인 코드를 제 자리로

[RosieOh]

Refs #132 (1a 단계. 0단계 #133 위에 쌓음)

왜

core 라는 한 패키지에 성격이 다른 셋이 섞여 있었다.

성격	도메인을 아는가
기반 (보안·웹·설정·저장소·유틸)	몰라야 한다
조합 (공공데이터 연동·배치·지오코딩)	아는 게 본질이다 — 도메인 참조 47건
도메인 (시설 공개 API 2개, 지원금 계산기)	도메인이다

조합 코드가 "공통 기반" 자리에 있으면 규칙을 세울 수조차 없다(도메인 참조가 정상이므로). 0단계에서 "core 는 domain 을 의존하지 않는다" 규칙이 373건을 잡은 것이 그 증거다.

이동

전	후
core/client	external/publicdata
core/geocoding	external/geocoding
core/scheduler	batch
core/devtools	devtools
core/benefit	domain/policy/benefit (policy 만 쓰던 도메인 로직)
core/controller/CareFacilityApiController (373줄)	domain/careFacility/controller
core/client/controller/PublicDataController	domain/careFacility/controller
core/controller/BaseController	core/web (패키지 해체)

integration 이라는 이름은 쓰지 않았다 — 테스트 쪽에서 이미 "통합 테스트" 뜻으로 쓰고 있어 같은 이름이 두 뜻으로 읽힌다.

총 위반은 줄지 않았다 (489 → 489)

솔직하게 적는다. "core 에 컨트롤러" 2건이 careFacility 네이밍 위반 2건으로 옮겨 간 것이다(옮긴 코드가 이제 도메인 규칙 대상이 된다). 숫자는 다음 PR(careFacility→facility, 98건 일괄)에서 줄어든다.

이 단계의 값은 숫자가 아니라 규칙을 예외 없이 적용할 수 있는 구조가 된 것이다.

규칙	전	후
core 에 컨트롤러	2	0
careFacility 소문자 아님	96	98
나머지	동일	동일

baseline 을 다시 뜬 이유

위반 설명에 클래스 경로가 들어가므로 파일을 옮기면 같은 문제도 새 위반으로 잡힌다. freeze.refreeze=true 로 한 번 다시 뜨고, 규칙별 숫자가 늘지 않았음을 확인한 뒤 false 로 되돌렸다(그래야 CI 가 진짜 새 위반을 잡는다). 이 절차를 문서에 적어 뒀다.

테스트

코드 변경 없이 이동과 import 재작성만 했다. 전체 600 tests, 실패 0, skip 0