docs(graphql): 43-leaf 레지스트리 사실에 맞게 sub-package 근거를 정정

main 통합으로 messaging 플랫폼이 24개 leaf 를 modules.json 에 등록한 것이 드러났다
(현재 총 43개 leaf). 따라서 "레지스트리는 정확히 19개로 고정되어 있고 확장하면 게이트가
깨진다"는 기존 서술은 사실과 다르다.

- 레지스트리는 확장 가능하며, 자매 플랫폼 messaging 은 정반대 패턴(leaf 등록)을 택했다.
- graphql 의 sub-package 매핑은 "레지스트리가 닫혀서"가 아니라 "GraphQL 표면은 하나의
  인바운드 전송 경계이고 그 내부 분할을 레포 전역 SSOT 까지 올리지 않는다"는 선택으로
  다시 서술한다.
- 두 패턴이 공존하므로 통일 여부는 미결 아키텍처 결정으로 명시한다. 모듈 레코드는 그대로
  leaf 명세로 승격 가능한 형태라 분해 비용은 낮게 유지된다.

루트 CLAUDE.md 도 여전히 "exactly 19 leaf identities" 라고 적혀 있으나 이는 messaging 머지에서
비롯된 선행 불일치이므로 이 커밋 범위 밖으로 두고 보고한다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/adapter/inbound/graphql/CLAUDE.md

@@ -15,10 +15,23 @@ Package root: `dev.caskeleton.adapter.inbound.graphql`.
 
 ## 플랫폼 모듈 = sub-package (Gradle 모듈 아님)
 
-GraphQL 플랫폼 설계서는 Stable 16개 + Advanced 12개 "모듈"을 말하지만, 이 레포의 leaf 정체성
-SSOT 는 `src/config/architecture/modules.json` 이고 거기에는 **정확히 19개 leaf** 만 존재한다.
-따라서 설계서의 28개 모듈은 이 leaf 안의 **bounded sub-package** 로 매핑한다(선례: httpclient
-leaf). 대신 모듈 경계는 문서가 아니라 기계가 지킨다:
+GraphQL 플랫폼 설계서는 Stable 16개 + Advanced 12개 "모듈"을 말하지만, 이 구현은 그 28개를 이
+leaf 안의 **bounded sub-package** 로 매핑한다(선례: httpclient leaf 가 366개 java 파일을 같은
+방식으로 담는다). GraphQL 표면은 하나의 인바운드 전송 경계이고, 그 내부 분할을 leaf 정체성
+SSOT(`src/config/architecture/modules.json`)까지 밀어올리지 않는다는 선택이다.
+
+**이는 레지스트리가 닫혀 있어서가 아니다.** `modules.json` 은 확장 가능하며, 실제로 자매
+플랫폼인 messaging 은 **정반대 선택**을 해서 24개 leaf 를 레지스트리에 등록했다(현재 총 43개
+leaf). 즉 이 레포에는 두 패턴이 공존한다:
+
+| | 방식 | 경계 강제 |
+| --- | --- | --- |
+| messaging | 레지스트리에 leaf 등록 | Gradle 의존 게이트 |
+| graphql | 단일 leaf 내 sub-package | 아래 경계 테스트 |
+
+어느 쪽으로 통일할지는 **미결 아키텍처 결정**이다. graphql 을 leaf 로 분해하려면 이 문서의
+모듈 레코드가 그대로 leaf 명세로 승격될 수 있게 설계해 두었다. 그때까지 모듈 경계는 문서가
+아니라 기계가 지킨다:
 
 - `build/GraphQlStableModule` · `build/GraphQlAdvancedModule` 이 모듈 정체성과 허용 의존 edge 를
   값으로 선언하고, `build/GraphQlBuildModel` 이 실제 소스 트리를 스캔한다.