필드 판정 — token_links 확정

확정  공용 10 · 최적화용 5 · 제거 2   (총 17 · 보류 없음)

확정된 token_links 스키마  — append-only 관측 로그
{
  _id                ObjectId   ●
  token_address      string     ●   mint 주소. ObjectId 를 쓰지 않는다 — 토큰은 재분류·병합이 없다
  object             enum       ●   contents | accounts | venues
  object_id          ObjectId   ●   {object_id, linked_at} 이 "이 객체를 건 토큰 수" 의 유일한 경로

  source_url         string     ●   재할당의 안전장치. object_id 는 바뀌어도 이 값은 안 바뀐다
  linked_at          Date       ●   as-of 절단축. 덮어쓰면 순번이 복원 불가
  observed_at        Date       ●
  status             enum       ●   ok · deleted · unavailable · unresolved
                                     상태 이력의 유일한 자리 — contents.fetch_status 를 제거했으므로
  name_match         bool       ○   title 이 가변이라 나중에 재계산 불가 → 관측 시점에 남긴다

  platform           enum       ●   최적화용 대상에서 복사. 플랫폼별 집계를 1회 조회로
  subtype            enum       ●   최적화용 draft 의 "tiktok search vs video 비교" 가 여기서 끝난다
  first_transfer_at  Date       ○   최적화용 Δt 계산 조인 0회. token_created_at 을 대체
  lineage[]          ObjectId[] 기본값 []  최적화용 자기+조상, 길이 상한 2
  link_depth         number     ●   최적화용 lineage.length − 1

  created_at/updated_at  Date   ●
}

제거 2  content_key(= 유실 문제의 원인) · source_field(칸 구분이 지켜지지 않음)

질문 1 · 이 필드로 쿼리하는가?   아니오 → data   예 → 질문 2
질문 2 · 의미가 모든 대상에서 같은가?   아니오 → data   예 → 질문 3
질문 3 · 원본(SoT)이 다른 곳에 있는가?   예 → 최적화용   아니오 → 공용

필수 여부
  필수 ●  없으면 저장 불가    기본값  항상 존재    선택 ○  없을 수 있음

이 컬렉션의 쟁점 3개
  1. token_address 를 무엇으로 참조할지
     이름 규칙상 문자열이면 token_key, ObjectId 면 token_id 다.
     주소는 불변이고 tracker 와 주고받는 값이라 문자열이 편하지만,
     다른 참조가 전부 ObjectId 인 것과 어긋난다.

  2. lineage[] · link_depth 를 유지할지
     원본은 contents.parent_content_id 체인이라 파생값이다.
     유지하면 "$or 없이 실질 재사용 세기" 가 되고, 빼면 매번 체인을 펼쳐야 한다.

  3. name_match 를 여기로 받을지
     venues 에서 "토큰과 비교한 파생값" 이라 제거했다.
     저장한다면 (토큰, 객체) 쌍의 속성이므로 여기가 자리다.

이 컬렉션만의 제약
  append-only. status 가 ok → deleted 로 바뀐 시각이 신호라 덮어쓰면 복원 불가.
  contents 에서 fetch_status 를 제거했으므로 상태 이력은 여기에만 남는다.