필드 판정 — venues 확정

확정  공용 12 · 개별(data) 3 · 제거 5   (총 20)

확정된 venues 스키마
{
  _id                ObjectId   ●
  platform           enum       ●   x · rd · tg
  subtype            enum       ●   community · subreddit · channel · portal · shell · guard_group
                                     accounts 와 달리 유지 — tg 가 같은 URL 에서 셋으로 갈린다
  platform_key       string     ○   x community id · rd slug(불변) · tg 는 groupId(guardChatId)
                                     tg 채널명은 mutable — 이관 실측 2건. 포털이 아니면 채널명뿐(한계)
  source_urls[]      object[]   ●

  name               string     ○
  description        string     ○   토큰 CA 가 실제로 여기 노출된다(설계 §1.5 실측)
  venue_created_at   Date       ○   "런치 직전 급조" 신호. rd 는 현재 수집 경로 없음
  creator_id         ObjectId   ○   accounts. 핸들 fallback 금지
  metrics.members    number     ○   accounts.followers 와 같은 판단

  observed_at        Date       ●
  created_at/updated_at  Date   ●
  data               Mixed      기본값 {}   moderators · adminHandle
}

제거 5  data.nameMatch · channel_state · data.subredditSubscribers · venue_key · ext
channel_state 제거  portal/shell/active 를 subtype 이 담당한다. 둘 다 두면 같은 사실이 두 곳
nameMatch 제거      토큰과 비교한 파생값이라 venues 속성이 아니다. 질의 시점에 다시 계산한다

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

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

이 컬렉션의 쟁점 3개
  1. data.nameMatch      채널명↔토큰명 일치 여부. 토큰과 비교한 파생값이라 venues 속성이 아닐 수 있다.
                            같은 채널을 여러 토큰이 쓰면 토큰마다 답이 다르다 → token_links 쪽 값?
  2. channel_state       tg portal/shell/active 를 subtype 으로 표현할지 별도 필드로 둘지. 둘 다 두면 중복.
  3. data.subredditSubscribers  contents 판정에서 "venues 쪽 값" 이라 했던 것.
                            여기 metrics.members 와 같은 값이라 제거 후보.

accounts 와 다른 점
  subtype 을 유지한다. tg 는 같은 t.me/{name} URL 이 관측 후 channel/portal/shell 로 갈리므로
  platform 만으로 종류가 결정되지 않는다. accounts 는 결정되어서 제거했다.