feat: 시설을 고르지 않아도 입소 확률을 볼 수 있게 한다

[RosieOh]

Closes #139

입소 확률은 GET /facilities/{facilityId}/admission-forecast 로만 볼 수 있었습니다. 시설을 먼저 골라야 숫자가 나온다는 뜻인데, 이 기능이 필요한 사람은 대개 어디를 고를지 모르는 쪽입니다. 구 안의 어린이집을 하나씩 눌러 확률을 모아야 하니 실질적으로 그 숫자를 영영 보지 못합니다.

질문을 뒤집어 지역·월령으로 받고 확률 순으로 돌려줍니다.

GET /facilities/admission-candidates?region=성동구&childAgeMonths=18

지켜야 했던 것

• 같은 계산기를 쓴다. 시설 상세에서 본 확률과 목록에서 본 확률이 다르면 둘 다 믿을 수 없게 됩니다. 반 이름 규칙도 양쪽이 각자 들고 있으면 갈라지므로 AdmissionForecastCalculator 로 끌어올렸습니다.
• 모르는 건 지어내지 않는다. 관측이 모자란 시설은 확률을 만들지 않고 notEnoughDataCount 로 셉니다. 후보 40곳 중 3곳만 나왔을 때 그 사실을 숨기면 "이 동네에 어린이집이 3곳뿐인가" 로 읽힙니다.
• 확률이 같으면 근거가 두꺼운 쪽을 위에. 같은 숫자라도 관측이 많은 편이 낫습니다.
• 쿼리는 한 번. 구 단위로 어린이집이 수백 곳이라 시설마다 관측을 따로 읽으면 추천 한 번에 수백 번 왕복합니다. findHistories 로 한 번에 읽고 시설별로 나눕니다 — 테스트가 호출 수를 고정합니다.
• 확률과 함께 그 확률의 신뢰도를. 이 기간 예측이 과거에 얼마나 맞았는지(accuracy)를 함께 줍니다. 숫자만 나열하면 그 숫자가 혼자 커집니다.

리뷰 중 고친 것 — 검증 실패가 500 이었다

처음에는 검증을 CareServiceException 으로 던졌는데, 그 예외의 기본 매핑이 500 입니다. 음수 월령 같은 잘못된 요청에 서버 오류가 나가고 운영 알림까지 울립니다. #132 2단계에서 고친 것과 같은 뿌리의 문제입니다.

실패하는 테스트로 500 을 먼저 확인한 뒤(expected: 400 but was: 500) BusinessException(ErrorCode.INVALID_INPUT)으로 바꿨고, ClientErrorStatusTest 에 "값이 범위를 벗어난 파라미터는 400" 을 남겼습니다. 빠진 파라미터는 Spring 이 알아서 400 을 내지만, 값이 범위를 벗어난 경우는 서비스까지 들어와 다시 500 이 되므로 새 API 마다 반복됩니다.

숫자

• OpenAPI: 231 → 232 경로, 158 → 160 스키마
• 전체 테스트 617개, 실패 0