[REFACTOR] PriorityResolver chain → publisher 측 이동 + 모든 PublishX 통과 (#385 Sub 6)

[juhy0987]

부모

부모 이슈: #385
의존: Sub 1~5

작업 범위

1. `internal/processor/fetcher/worker/resolver.go` → `internal/publisher/resolver.go` 이동

• `PriorityResolver` / `ChainablePriorityResolver` / `CompositeResolver` / `ExplicitPriorityResolver` / `SourcePriorityResolver` / `RuleBasedPriorityResolver` / `DefaultPriorityResolver` 모두 이동

2. Publisher 의 모든 PublishX 가 resolver chain 통과

```go
func (p *Publisher) publishCore(ctx, job *core.CrawlJob, headers map[string]string) error {
priority := p.resolver.Resolve(job)
topic := topicForPriority(priority)
...
}

// PublishSeed / PublishChained / PublishRetry / PublishUpgrade 모두 publishCore 통과
```

3. 일관성 효과

• 시드, chained, retry, upgrade 모든 경로가 동일 resolver chain 통과
• 운영자가 한 곳에만 resolver 룰 추가하면 모든 경로에 적용
• ExplicitPriorityResolver 가 chain 1순위 → entry.Priority / job.Priority 명시 시 우선

4. 테스트

• 기존 worker resolver 테스트 → publisher resolver 테스트로 이동
• 각 PublishX 의 resolver 통과 검증 (integration test)

영향 / 위험

• Low — 파일 이동 + import path 변경. resolver 로직 자체 무변경.
• 본 Sub 머지로 [FEATURE] Publisher 통합 모듈화 + Kafka I/O 단일 책임 분리 (메타) #385 메타 완료 + [FEATURE] 크롤러 우선순위 동적 분배 — 3-tier resolver chain 진화 (메타) #380 (Sub A 재작성) 진행 가능

완료 조건

• resolver 파일 publisher 측 이동
• 모든 PublishX 가 resolver 통과
• 기존 resolver 테스트 그대로 통과
• worker 측에 PriorityResolver 인터페이스 잔존 X (publisher 가 단일 source)