docs: derivation-cache spec/handoff 독자 관점 보강

PR #195 구현(e9b5202) 기준으로 빠졌던 디테일 보강:
- chunk_id(위치 기반 벡터 식별자) vs cache_key(내용 해시 조회 키) 구분 callout
- §7 호환성/마이그레이션 신설: 본문 재색인 불필요, V012 가산이나 binary 교체 필요,
  별칭 sentinel 묶음→개별 변경의 기존 KB 영향(레거시 호환)
- version_key 에 kind 토큰("doc|") 반영, orphan sentinel cleanup(LIKE prefix) 명시
- embed_with_cache 순서 보존 불변, 별칭 개별 벡터 근거(희석 13/18→16/18)
- 정정: derivation_cache_gc 는 메서드만 존재하고 미연결(캐시 현재 무한 누적, 후속)

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

docs/superpowers/handoffs/2026-05-31-namu-wiki-alias-cache-study.md

@@ -79,9 +79,15 @@ chunk_id 캐싱은 중간 수정 시 무력 → **청크 text 내용 해시**를
 - `derivation_cache(cache_key, kind, payload, created_at, last_used_at)` (SQLite, V012).
 - `cache_key = blake3(kind ‖ text_blake3 ‖ version_key)`. version_key 에 model/prompt/
   dimensions 포함 → §9 cascade 와 정합(버전 bump 시 자동 miss).
+- **위치 밀림에도 캐시가 듣는 이유**: chunk_id 는 위치(ordinal+span) 기반이라 문서 중간
+  삽입 시 뒤 청크의 chunk_id 가 바뀌어 row 가 재작성되지만(싼 DB write), cache_key 는
+  *내용 해시*라 내용 불변 청크는 히트 → 비싼 재계산(embedding/LLM) 0. chunk_id 와
+  cache_key 가 별개라는 게 핵심. 설계 근거·동작은 spec §1 / §3.4 참조.
 - 적용: embedding(본문 + 별칭 벡터 양쪽) + 별칭 LLM. korean_tokens 는 우선순위 낮아 보류.
 - **측정: 정답 3개 cold 1879초(31분) → warm 13초 ≈ 145배.** 18문서 환산 시 2.5h → ~80s.
   derivation_cache 1237 엔트리(alias 140 + embedding 1097).
+- 기존 KB 호환성(본문 재색인 불필요 / V012 가산 / 이전 binary mismatch / 별칭 재생성은
+  선택)은 설계 spec §7 참조 — 이 handoff 는 측정 과정·결과만 담는다.
 
 ## 5. KB 이식성 (외부 계산 워크플로)