feat(HNT-2896): start the crawl-worker by role

[mmiermans]

Goal

HNT-2896

Add the crawl-worker entry point, which initializes the shared API clients and starts the consumer matching this pod's WORKER_ROLE so one image runs as either the article or discovery worker, and drains in-flight work cleanly on SIGTERM. This builds on the article consumer, discovery consumer, and Zyte rate limiter slices by wiring them together into the entry point. See docs/ARCHITECTURE.md in #14 for the single-image two-worker system.

Implementation decisions

Decision	Approach	Why
Dispatch on WORKER_ROLE and fail fast on an unknown role	start runs the article consumer or the discovery consumer, and throws before any client init when the role is neither	The worker Helm values run both workers from one crawl-worker image selected by WORKER_ROLE, deployed as two independently scalable Deployments. Failing fast stops a mislabeled or unset-role pod from running silently.
Drain Pub/Sub before flushing metrics and Sentry, then close Redis, then the health server	shutdown awaits the drain, then shutdownMetrics and shutdownSentry, then shutdownRedis, and closes the server last with closeAllConnections	Handler errors are captured while the drain finishes, so draining first keeps those errors buffered for the flush. The metrics and Sentry flush then runs before the Redis quit rather than after it, because a slow Redis quit sitting between the drain and the flush could let the 28s force-exit kill the flush and drop those drain-time errors. Redis closes next since in-flight handlers use it, and the health server closes last so its probe keep-alive sockets are force-closed and close() resolves promptly.
Bound total shutdown at 28s, above the Pub/Sub drain and inside the pod grace period	A setTimeout force-exits at 28s	Kubernetes sends SIGTERM and then SIGKILLs after the grace period, 30s by default, so the 28s force-exit guarantees the process exits first, while staying above the pubsub package's 25s drain timeout lets the drain complete.
Gate the Corpus API client on the JWK, and only for the article role	The article role calls initCorpusApi, which skips the client when CORPUS_API_JWK_JSON is unset, and the discovery role never initializes it	Only the article worker syncs live articles, and the endpoint, issuer, and audience have app defaults, so the JWK secret is the only required input. Skipping the client when it is absent lets a local run that only processes discovered articles start.