docs: 감사 6라운드 반영 — lifecycle-pattern 순환 절 인용 제거·스케치에 필드 프레이밍 주석, ref-plan 같은-파일 인용 둘 정정

Co-authored-by: qwreey <me@qwreey.moe>

.claude/base/lifecycle-pattern.md

@@ -294,7 +294,11 @@ InstData:SetWeak(inst, "gcconn", gcconn)
 #### (1) `bindLifetime` / `unbindLifetime` / `canBound` / `canExecute`
 
 ```lua
--- quad-roblox 실 구현 스케치
+-- quad-roblox 실 구현 스케치. [2026-08-28] 아래 `function bindLifetime(...)` 등은
+-- 읽기 편하게 평범한 함수로 적었지만, 실제로는 InitLifetimeHandle이 심어둔
+-- 모듈 인스턴스 필드(module.bindLifetime 등)에 최종 대입되는 본체다 — 위
+-- "탑레벨 평범한 함수로 확정" 절의 정정 참고. mock 백엔드(test/mock.luau의
+-- installLifetime)가 이 스케치를 그 모양으로 옮긴 실물이다.
 local InstData = Relate() -- inst  -> gchold/gcconn (위 (0)에서 채워짐)
 local BindData = Relate() -- value -> gchold/gcconn (bindLifetime이 채움)
 
@@ -772,7 +776,8 @@ store-plan.md`가 예전에 "state 옵저빙 결과로 slot을 조작할 때 생
 Destroy 시 모든 커넥션을 즉시 끊어주지만, 다른 엔진에서도 라이프사이클을
 확인할 수 있어야 하므로 base는 "이 바인드가 아직 유효한가"를 묻는 람다/인터페이스만
 정의하고, quad-roblox가 그 구현을 Roblox의 실제 `Connected`로 채워넣는다(구현
-주입 방식은 아래 "`Connected` 체크는 rbvm 패턴을 그대로 베끼는 게 아니라" 절 참고). 이게
+주입 방식 — 모듈 인스턴스 필드를 백엔드 팩토리가 뮤테이션 — 은
+`base/module-lifecycle-plan.md`가 base 유틸 전반에 대해 일반화해둔 것과 같다). 이게
 필요한 이유: rbvm처럼 GC 트릭으로 라이프사이클을 연결하면 GC가 즉발이 아니라서
 중간에 죽은 참조가 남아있을 수 있고, 그 시점에 store에 새 값이 들어오면 죽은
 대상에 처리를 시도하다 터질 수 있음 — 그래서 처리 직전에 유효성을 확인.

.claude/base/ref-plan.md

@@ -712,8 +712,8 @@ flatten된 값은 해시 파트(프로퍼티 키)로 존재하게 되고, Store
   처리한다"처럼 구현을 단정하는 용법은 폐기**다.
   - **복수 `PreRef` 간 순서(2026-08-07 아홉 번째 세션 확정, 2026-08-14
     아홉 번째 세션 재확인) — 새 규칙 불필요, 배열 index 순서 그대로
-    보장.** 같은 인스턴스에 `PreRef`가 여럿 있으면, 이 pre-pass는 위
-    "props 순회 순서" 절이 이미 확정해둔 "배열 파트는 index 순서대로"
+    보장.** 같은 인스턴스에 `PreRef`가 여럿 있으면, 이 pre-pass는
+    `base/dispatch-core-plan.md`의 "props 순회 순서" 절이 이미 확정해둔 "배열 파트는 index 순서대로"
     계약을 그대로 재사용해 리터럴 순서대로 fire함 — 서로 다른 우선순위/
     순서 개념을 별도로 만들 필요 없음(호이스팅은 "PreRef 전체 대 나머지"에만
     적용되는 규칙이지, "PreRef끼리"에는 적용될 게 없음 — PreRef끼리는
@@ -817,7 +817,7 @@ flatten된 값은 해시 파트(프로퍼티 키)로 존재하게 되고, Store
     매치한 Handler"라고 적혀 있었으나 중간 노드가 매치되는 경우가 있어
     말단 기준으로 정정됨) — 매치되는 Handler 자신이 곧 등록자라 "누가
     등록하는가"라는 질문 자체가 안 생김. 반환하는 retract는 하드코딩된
-    no-op인데, 이건 "PreRef는 취소 개념이 없다" 절(아래)이 말하는 것과
+    no-op인데, 이건 "PreRef는 '취소'라는 개념이 없다" 절(아래)이 말하는 것과
     같은 이유 — fire가 이미 실행한 부작용은 되돌릴 수 없으므로 이 자리가
     dispatch 체인에 실제로 올라가 있어도(**[정정] 예전 서술과 달리 이제는
     올라가 있음** — 아래 참고) retract가 할 일이 없는 것뿐.