feat(HNT-2117): add the agent tick enqueue loop

[mmiermans]

Goal

HNT-2117

Add the agent's per-tick enqueue loop. runTick publishes a discovery job for each page and a crawl-article job for each live article whose crawl interval has elapsed since it was last enqueued, and returns the counts for logging.

This builds on the redis-state slice for the enqueue markers, the pubsub package for publishing, the crawl Redis key builders, and the crawl domain message types. See docs/ARCHITECTURE.md in #14 for where the tick sits between the publisher list and the crawl queues.

Implementation decisions

Decision	Approach	Why
Dedup enqueues with agent-owned markers rather than the worker fetch keys	runTick reads and writes its own page:enqueued and article:enqueued markers, not the worker-written page:fetch and article:fetch keys.	There is a window between the agent enqueuing an item and the worker recording its fetch, so reusing the worker fetch marker for dedup would let the agent re-enqueue the same item on every tick during that window. An agent-owned enqueue marker closes that gap.
A plain check-then-set on the enqueue marker, with no distributed lock	Each item reads its Redis enqueue timestamp and, when due, publishes and then writes a fresh timestamp, with no lock or atomic guard.	The agent runs as a single replica, so no two ticks race the same marker. Within a tick the items are enqueued concurrently, but validatePublisherList rejects duplicate URLs, so no two list entries contend on the same key either. A distributed lock would add cost with no benefit.
Publish before marking enqueued	Publish the job first, and only on success write the enqueue timestamp.	A failed publish leaves no marker, so the item is retried on the next tick rather than being suppressed until its interval elapses, and the error propagates so a broken publisher fails the tick visibly.
Compare the stored timestamp for dueness, not a marker TTL	enqueuedWithin compares elapsed time against interval_minutes using the value stored in Redis, and the marker's own TTL is unrelated to the interval.	Encoding the window in a TTL would tie each item's cadence to the tick interval and misfire for short intervals. Comparing the stored timestamp keeps the cadence exact and independent of how often the loop runs.
Shape the live-article job with source_url equal to the article URL and a matching refresh window	The job carries the unchanged corpus_item, a fresh crawl_id per enqueue, source_url set to the article URL, and refresh_interval_minutes set to the agent's live-article interval.	A live article has no discovery page, so source_url is the article itself. The worker dedups against refresh_interval_minutes, so matching it to the agent's live-article interval keeps the worker's refresh window aligned with the agent's cadence rather than the worker default.

[mmiermans]

Ripple notice, no change requested here yet. Once #35 and #19 land, tick.ts picks up the renames: enqueueLiveArticleIfDue reads config.liveArticleIntervalMinutes twice, for the enqueuedWithin gate and for the job's refresh_interval_minutes, and both become the collapsed LIVE_ARTICLE_REFRESH_MINUTES (which replaces corpusRefreshMinutes too); the message field itself becomes article_refresh_minutes, and enqueuePageIfDue reads page.interval_minutes, renamed page_refresh_minutes. The articleEnqueuedKey and pageEnqueuedKey gates are unaffected.

[mmiermans]

The page due-check reads config, not the page entry

The page crawl cadence becomes a single global configuration value, so enqueuePageIfDue stops reading page.interval_minutes and passes the scheduler's configured value to enqueuedWithin instead (pageRefreshMinutes in #35). enqueuedWithin keeps its signature and the pageEnqueuedKey marker is unaffected, so this is a one-line change in the function plus dropping the field from the page fixtures in tick.spec.ts and tick.integration.ts. The live-article path does not change: it already reads a global cadence from config and sets the article message's own refresh window.

This supersedes the page half of the ripple notice above. page.interval_minutes is not being renamed to page_refresh_minutes, it is going away, and the value comes from config from here on. The live-article renames in that notice still stand.

Why: all 3,399 pages in publishers.json carry interval_minutes: 20, so nothing has ever used the per-page capability, while keeping it makes the value we do change expensive to change. Adjusting the cadence today means re-running the generator and committing a diff over every page entry, which is unreviewable in practice. docs/crawl/ARCHITECTURE.md calls the page crawl interval the one latency lever this repo owns and the main driver of Zyte volume, so it is at once the setting most likely to be tuned and the hardest to tune.

The trade-off: since the scheduler no longer stamps a window onto each job, a job already on the queue will be evaluated against whatever the discovery worker's setting says when it is handled rather than the value in force at enqueue time. Acceptable for a value that is uniform and changes rarely, but a real property being given up rather than an accident.

The capability is deferred rather than abandoned. If per-page or per-topic differentiation is wanted later, and the FPS "Zyte Cost Optimization" page does propose slower crawling for evergreen topics and overnight, it can be reintroduced deliberately at that point.