[REFACTOR] parser worker Kafka I/O → publisher facade (#385 Sub 7)

[juhy0987]

부모

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

배경

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

위치	책임
line 54: `*queue.KafkaConsumer` 필드	consume
line 248: `consumer.FetchMessage`	consume
line 270: `consumer.CommitMessages`	consume
line 782-788: `producer.Publish(TopicNormalized)`	publish (parsed page → validator)
line 839-849: `producer.Publish(TopicFetched)`	publish (chained article jobs)
line 889-900: `producer.Publish(TopicFetched)`	publish (chained category jobs)

fetcher Sub 5 와 동일 패턴: stage worker 가 Kafka I/O 직접 의존.

작업 범위

1. Kafka I/O 책임 publisher 로 이동

• `*queue.KafkaConsumer` 필드 → `publisher.Consumer` (Sub 5 에서 도입한 인터페이스)
• `producer queue.Producer` 필드 제거 → publisher facade 의존
• `producer.Publish(TopicNormalized, ...)` → `publisher.PublishParsed(ctx, ref)` (또는 `PublishToTopic` 일반화)
• `producer.Publish(TopicFetched, chained job)` → `publisher.PublishChained(ctx, ...)` (Sub 1 의 기존 메소드 재활용)

2. fetcher 책임 유지

• parsing rule 적용 / blacklist filter / 공통 worker 패턴 (worker pool / commit 정책) → 그대로 parser worker 잔존
• chained job 발행 시 카테고리 hint 결정 같은 parsing 측 의사결정도 그대로

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

• `parser.NewParserWorker(consumer, producer, ...)` → `parser.NewParserWorker(publisher, ...)`
• 기존 `queue.NewConsumer(TopicFetched)` 호출 제거 → `publisher.SubscribeFetched()`

4. 테스트

• 기존 mockProducer / mockConsumer → publisher facade mock
• parser worker 핵심 로직 (rule parse / blacklist / publisher 호출) 테스트 그대로

영향 / 위험

• Medium — stage worker 의 dependency 교체
• 라이브 영향 없음 (publish 시점/내용 동등)

완료 조건

• parser_worker 가 publisher facade 만 의존 (queue 직접 의존 X)
• consumer + 4종 publish 모두 publisher 통과
• parsing 핵심 로직 무변경
• race test 통과