move: move/affinity 검사 — v0 fast path 완성

보안 정리 (ii) — safe code에서 capability는 복제·위조되지 않는다 — 를 코드로
닫는다. 검사는 전부 함수 로컬 데이터플로우이고 전역 분석이 없다.

affinity의 뿌리는 capability다. 필드로 가진 타입은 전이적으로 affine이며
고정점까지 돌려 상호 재귀 타입도 유도한다. 이 전이가 없으면 wrapper 하나를
복사해 capability가 사실상 복제되므로 정리가 깨진다. copyable 선언과 affine
필드의 공존은 오류다.

구현한 규칙:
- affine 값은 소유 자리로 갈 때 move된다(own 파라미터, 반환, struct 저장,
  컨테이너 삽입, let 바인딩, by-move capture). moved 이후 사용은 오류이고
  진단이 어디서 소비됐는지를 말한다
- 분기 병합은 보수적 합집합. 한 분기에서라도 moved면 병합 이후 moved
- 빌린 값은 탈출하지 못한다: 반환, struct 저장, 소유 자리로 넘기기 전부 거부
- use의 전염: 빌린 값을 capture한 클로저는 그 자체가 빌린 값이라 소유 자리로
  갈 수 없다. 별도의 nonescaping 개념 없이 use 규칙 하나로 닫힌다
- callable affinity: affine 값을 capture한 클로저는 affine fn이며 fn 자리에
  갈 수 없다

자율 결정 둘:
- 클로저는 mut 바인딩을 capture할 수 없다. spawn만 막는 특수 규칙 대신
  일반 규칙으로 뒀다 — v0에 참조가 없으므로 별칭도 조용한 복사도 만들 수
  없고, spawn 제한은 이 규칙의 특수 사례가 된다
- v0에 부분 move는 없다. 필드 접근은 빌림이고 결과도 빌린 값이다.
  affine 필드만 꺼내려면 부분 move 상태 추적이 필요한데 v0가 살 복잡도가 아니다

05를 자족적으로 다시 썼다. affinity의 뿌리가 capability라 자원 타입을 모듈
안에서 정의해야 검사기가 affine임을 유도할 수 있다. 외부 타입은 affine임을
증명할 수 없으므로 copyable로 본다.

이로써 fast path(L0 parse / L1 type·effect·capability·ownership)가 완성됐다.
cool check가 처음으로 성공을 선언한다 — 01~04, 06, 07이 exit 0으로 통과한다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZVDeU6KLuUVL3gs18Hm3E

samples/README.md

@@ -12,7 +12,7 @@
 | 02_higher_order_effects | effect 변수, 구문 수준 제한, 명시적 인스턴스화 |
 | 03_scope_concurrency | TaskScope, 이름 있는 scope, 중첩 시 수명 표현 |
 | 04_enum_match_interface | enum 정의 본문이 interface surface에 들어가는 경로 |
-| 05_move_errors | **에러가 나야 하는** 코드 — 진단 하나씩 |
+| 05_move_errors | **move/affinity 검사기가** 거부해야 하는 코드 (자원을 직접 정의) |
 | 06_affine_closure | callable affinity (fn vs affine fn), own과의 직교성 |
 | 07_module_interface | interface artifact가 담아야 할 것 전부 |
 | 08_syntax_errors | **파서가** 거부해야 하는 코드 |
@@ -21,13 +21,16 @@
 
 05, 08, 09, 10은 통과하면 안 되는 파일이다. 각 함수 주석의 `[E-...]` 태그가
 기대 진단이며, 넷의 목적이 다르다 — **08은 파서가, 09는 타입 검사기가,
-10은 effect 검사기가, 05는 아직 없는 move/affinity 검사가** 거부해야 한다.
-단계별로 파일을 나눈 이유는 앞 단계가 첫 오류에서 멈추면 뒤 단계 케이스에
-영영 도달하지 못하기 때문이다.
+10은 effect 검사기가, 05는 move/affinity 검사가** 거부해야 한다. 단계별로
+파일을 나눈 이유는 앞 단계가 첫 오류에서 멈추면 뒤 단계 케이스에 영영
+도달하지 못하기 때문이다.
 
-09와 10에는 외부 타입이 하나도 없다. 전부 모듈 안에서 정의되므로 검사기가
-TUnknown으로 빠져나갈 구석이 없다 — 검사기에 이빨이 있는지 보는 파일이다.
-10은 capability를 직접 정의해야 메서드의 effect가 알려지므로 특히 그렇다.
+05, 09, 10에는 외부 타입이 하나도 없다. 전부 모듈 안에서 정의되므로 검사기가
+빠져나갈 구석이 없다 — 검사기에 이빨이 있는지 보는 파일들이다. 10은
+capability를 직접 정의해야 메서드의 effect가 알려지고, 05는 affinity의 뿌리가
+capability라 자원 타입을 정의해야 affine임이 유도된다.
+
+01~04, 06, 07은 `cool check`를 통과한다 (exit 0).
 
 파서는 첫 오류에서 멈춘다(오류 복구 미구현). 타입 검사기는 오류를 전부 모은다.