feat: add production capability foundations

src/application-core/README.md

@@ -14,6 +14,12 @@
 `verifyApplicationCoreDependencyPurity`와 ArchUnit
 `APPLICATION_HAS_NO_DIAGNOSTIC_FRAMEWORK`가 이 계약을 자동 검증한다.
 
+Cache 진단도 같은 원칙을 따른다. `CacheObservationEvent`는 code-owned bounded cache name,
+local/Redis tier, enum outcome과 finite duration/count만 표현하며 semantic key, user/tenant ID,
+endpoint를 담지 않는다. `CacheObservationPort`는 이 event를 전달하는 framework-free 경계이고,
+Micrometer meter/tag 렌더링은 Redis adapter가 소유한다. 관측 실패는 cache lookup/invalidation
+결과를 바꾸지 않는다.
+
 ---
 
 ## 유스케이스 계약 (usecase / command / query / capability)
@@ -71,13 +77,21 @@
 - **존재 이유**: application 유스케이스가 `org.springframework.transaction.annotation.Transactional`
   을 import 하지 않고도 트랜잭션 의도를 선언하게 하기 위한 추상화다. 구현(보통
   `SpringTransactionPort`)은 persistence adapter 가 Spring `PlatformTransactionManager` 로 제공한다.
-  application/domain 을 프레임워크-free 로 유지하는 핵심 장치.
-- 세 가지 경계:
+application/domain 을 프레임워크-free 로 유지하는 핵심 장치.
+- 네 가지 경계:
   - `inWrite` — REQUIRED + read-write, `READ_COMMITTED`. command 유스케이스 기본.
+  - `inRootWrite` — 물리 root 전용 REQUIRED + read-write, `READ_COMMITTED`. 실제 ambient
+    transaction 이 하나라도 있으면 action 실행 전에
+    `NestedRootTransactionRejectedException` 으로 거부한다. 성공 값은 commit 이 끝난 뒤에만
+    호출자에게 반환되며, commit 실패는 그대로 전파된다.
   - `inRead` — REQUIRED + read-only, `READ_COMMITTED`. query 유스케이스 기본.
   - `inNew` — REQUIRES_NEW + read-write. UseCaseCapability 에 `REQUIRES_NEW` 를 명시한
     유스케이스(outbox/audit/compensation)에서만 허용.
-- **콜백 시그니처(D11)**: 세 메서드 모두 `Supplier`/`Runnable` 을 받아 checked exception 을 던질
+- **root-only 사용 조건**: `inRootWrite` 는 join 가능한 일반 command 경계의 대체물이 아니다.
+  외부 효과를 commit 이후에만 시작해야 하는 orchestration처럼 물리 root를 증명해야 하는 경우에만
+  쓴다. 기존 transaction 안에서 `REQUIRES_NEW` 로 몰래 분리하지 않고 fail-fast하므로, 호출자는
+  transaction 없는 진입점에서 이 경계를 시작해야 한다.
+- **콜백 시그니처(D11)**: 네 메서드 모두 `Supplier`/`Runnable` 을 받아 checked exception 을 던질
   수 없다. Spring `TransactionCallback<T>` 제약과 동일하다. 그래서 호출자는 도메인 checked
   exception 을 `RuntimeException` 하위로 감싸야 한다(`DomainException extends RuntimeException`).
   `IOException` → `UncheckedIOException`, `SQLException` 은 Spring `DataAccessException` 계층이
@@ -93,7 +107,33 @@
   **금지**: 많은 레코드를 도는 루프 안에서 `inNew` 호출(예: per-row outbox dispatch). 풀 고갈 +
   데드락 위험. 레코드를 한 번의 `inNew` 안에서 배치 처리하거나, 루프를 트랜잭션 경계 밖으로 빼라.
 - **금지 목록**: `NESTED`/`NEVER` propagation, `READ_UNCOMMITTED` isolation, application 패키지에서
-  `@Transactional` 직접 사용, `inNew` 의 per-record 루프 호출.
+  `@Transactional` 직접 사용, `inRootWrite` 의 ambient transaction 진입, `inNew` 의 per-record
+  루프 호출.
+
+---
+
+## Notification R1 오케스트레이션 경계
+
+`dev.caskeleton.application.notification`은 알림 vendor 구현이 아니라 알림 capability의 순수
+애플리케이션 계약이다.
+
+- 입력은 typed recipient/template value와 코드 소유 `NotificationKindPolicy`로 제한한다. feature가
+  만든 `NotificationIntentDraft`는 `NotificationPlanPort`에서 immutable
+  `NotificationFrozenPlan`으로 고정되고, append/inline 포트는 이 plan만 소비한다.
+- dispatch는 claim → reserve/authorize → provider call → terminal-once finalize 순서다. 짧은 DB
+  transaction 사이에서 provider를 호출하며, opaque claim/version/execution token으로 stale 결과를
+  거부한다. submission certainty가 `INDETERMINATE`면 blind retry나 fallback을 하지 않는다.
+- receipt reducer는 fact 순서와 무관한 monotonic projection을 만든다. hard bounce/complaint만
+  technical suppression 후보이고, business consent/unsubscribe는 다른 capability가 소유한다.
+- admission/reconciliation/maintenance는 bounded batch와 주입된 `Clock`을 사용한다. scheduler는
+  이 유스케이스만 호출하며 store/provider 포트를 직접 조율하지 않는다.
+- legacy→canonical writer cutover는 exact route/generation/profile registry, root-only commit,
+  서명된 inventory/quiescence evidence와 closed transition action으로 표현한다. 애플리케이션은
+  verifier/operation 포트의 입력 계약을 강제하고, 실제 서명 검증·행 잠금·불변 journal·provider
+  egress 차단은 후속 adapter 구현이 증명해야 한다.
+
+현재 증거 등급은 **R1 application contract with fakes**다. PostgreSQL DDL/locking, provider
+protocol, receipt ingress, runtime wiring을 포함한 R2/R3 완료 주장이 아니다.
 
 ### TransactionMode