docs(security): 내부 사용자 컨텍스트 전파 규칙 반영

shared internal token과 internal user header의 역할을 분리하고, /internal/** 체인에서만 사용자 컨텍스트를 해석한다는 규칙을 문서에 반영했다.

Constraint: 현재 mixed-mode 호환 정책과 구현 현실을 문서가 과장 없이 반영해야 함
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: 내부 호출 정책이 바뀌면 filter_arch와 dependencies 문서를 함께 갱신할 것
Tested: Not run (documentation only)
Not-tested: Future docs/examples consistency outside edited files

Author: YeaChan05

docs/filter_arch.md

@@ -33,16 +33,28 @@
 `transfer:service -> transfer:infrastructure -> member|account:api-internal.internal.contract` 구조를
 따른다.
 
+현재 `api-internal.internal.contract`는 Spring HTTP interface(`@HttpExchange`)로 정의된다.
+provider application은 `/internal/**` endpoint를 노출하고, consumer는 Spring HTTP Service proxy로 호출한다.
+
 ## common:security 의 역할
 
 `common:security`는 공통 보안 기술 구현을 제공한다.
 
 - `TokenParser`, `TokenVerifier`, `TokenGenerator`
 - `JwtAuthenticationFilter`
+- `InternalServiceAuthenticationFilter`
 - `AuthenticationEntryPoint`, `AccessDeniedHandler`
 - 기본 `SecurityFilterChain`
 - 기본 `AuthorizeHttpRequestsCustomizer`
 
+도메인 간 `/internal/**` 호출은 기본적으로 `X-Internal-Token` shared secret을 유지한다.
+추가로, 사용자 컨텍스트가 필요한 내부 호출은 `X-Internal-User-Id` 헤더로 caller memberId를 전달한다.
+
+provider 쪽 `/internal/**` 전용 필터는 이 헤더를 읽어 내부 요청의 `Authentication.name`에 memberId를 세팅할 수 있다.
+이 값은 `/internal/**` 체인에서만 해석하며, 외부 공개 경로에서는 절대 사용자 신원으로 해석하지 않는다.
+
+기존 internal caller와의 mixed-mode 전환 기간에는 `X-Internal-User-Id`가 없는 호출도 임시 호환하되, 경고 로그를 남긴다.
+
 각 API 모듈은 자신만의 `AuthorizeHttpRequestsCustomizer`를 추가 등록해 공개 경로를 선언한다.
 
 ## 경로 정책
@@ -81,5 +93,6 @@ auth:
 
 - `aggregate`는 로컬 조합용 runnable application이며, 정규 API 통합 테스트의 기준점은 아니다.
 - `/login` 책임과 회원 인증 책임은 모두 `member` 도메인이 가진다.
+- 내부 사용자 식별자 전달은 AOP 대신 기존 `@LoginUserId` / `LoginUserIdArgumentResolver` 패턴 재사용을 우선한다.
 - 인증 정책 문서를 수정할 때는 `AggregateSecurityConfiguration`, `CommonSecurityAutoConfiguration`,
   `member:api/MemberLoginController`를 함께 확인한다.

docs/rule/dependencies.md

@@ -11,6 +11,10 @@
 - `service -> other-domain:infrastructure` 는 금지한다.
 - `service -> other-domain:api-internal` 도 금지한다.
 - 내부 통신은 `consumer:infrastructure -> provider:api-internal.internal.contract` 경로만 허용한다.
+- 내부 통신 계약은 Spring HTTP interface(`@HttpExchange`)로 정의하고, consumer는 Spring HTTP Service proxy로 호출한다.
+- 내부 사용자 컨텍스트가 필요하면 consumer `infrastructure`가 transport header(예: `X-Internal-User-Id`)를 전파하고,
+  provider는 `/internal/**` 전용 필터 + 기존 controller argument resolver 패턴으로 해석한다.
+- 외부 공개 경로에서는 internal user header를 사용자 신원으로 해석하지 않는다.
 - 예외: 인증/암호화가 필요한 유스케이스는 `common:security` 의존을 허용한다.
 - `api` 와 `implementation` 은 다음 의미를 가진다.
 
@@ -244,6 +248,7 @@ graph LR
 - model은 아무것도 의존하지 않는다
 - service는 계약(infrastructure)만 안다
 - 내부 통신은 consumer infrastructure가 provider api-internal을 감싼다
+- provider application은 `/internal/**` endpoint를 노출하고, 내부 호출 인증은 shared internal token으로 처리한다
 - repository는 구현이지만 core를 거꾸로 끌어오지 않는다
 - api는 orchestration을 하지 않는다
 - application은 조립만 한다