[REFACTOR] validate worker + cmd/processor Kafka I/O → publisher facade (#385 Sub 8)

[juhy0987]

부모

부모 이슈: #385
의존: Sub 1 (publisher facade) + Sub 6 (resolver chain 이동) — 단, 병렬 진행 가능

배경

`internal/processor/validate/worker.go` 의 Kafka I/O:

위치	책임
line 35: `queue.Consumer` 필드	consume
line 126: `consumer.FetchMessage`	consume
line 373-384: `producer.Publish(TopicValidated)`	publish (검증 통과 → downstream)
line 457-464: `producer.Publish(TopicDLQ)`	publish (검증 실패 → DLQ)
line 495-504: `producer.Publish(TopicNormalized)`	publish (재큐잉)
line 585+: republishForReparse	publish (validator → parser 재학습 trigger, #366)

`cmd/processor/main.go` 도 `queue.NewConsumer` / `queue.NewProducer` 직접 wiring (validator 단독 실행 바이너리).

작업 범위

1. validate worker Kafka I/O 이동

• `queue.Consumer` 필드 → `publisher.Consumer`
• `producer queue.Producer` 필드 제거 → publisher facade 의존
• 4종 publish (validated / dlq / requeue / reparse) → publisher facade 메소드:
  • `publisher.PublishValidated(ctx, ref)`
  • `publisher.PublishToDLQ(ctx, msg, reason)`
  • `publisher.PublishRequeue(ctx, msg, pm)` — backoff 정책 포함
  • `publisher.PublishReparse(ctx, content, count, reason)` — [FEATURE] validator → parser 재학습 — parser worker header 수신 + LLM 호출 시 reason 전달 + 라이브 검증 (#363 Sub C) #366 의 reparse 흐름

2. fetcher 책임 유지 (validate 측)

• validation 핵심 로직 (RunValidation, IsReparseEligible, validation_status 갱신) → validate worker 잔존
• DLQ / requeue 의사결정 (RetryCount / maxRetries 비교, IsReparseEligible 판단) → validate worker 잔존
• 단순 Kafka publish 호출만 publisher 위임

3. `cmd/issuetracker/main.go` + `cmd/processor/main.go` wiring 갱신

• 양쪽 entry point 모두 `validate.NewWorker(publisher, ...)` 사용
• 기존 `queue.NewConsumer(TopicNormalized)` / `queue.NewProducer(...)` 호출 제거
• cmd/processor 의 wiring 도 publisher facade 도입

4. 테스트

• 기존 validate worker_test.go 의 mockProducer / mockConsumer → publisher facade mock
• validation 로직 / reparse trigger / DLQ 분기 테스트 그대로

영향 / 위험

• Medium — stage worker 의 dependency 교체
• 라이브 영향 없음
• cmd/processor 별도 entry 도 동일 wiring 패턴 — 정합성 확보

완료 조건

• validate worker 가 publisher facade 만 의존
• consumer + 4종 publish 모두 publisher 통과
• validation 핵심 / 의사결정 로직 무변경
• cmd/issuetracker + cmd/processor 양쪽 wiring 갱신
• race test 통과