fix(ingest): avoid re-ingesting 10s every cron cycle for single-instance jetstream

[tompscanlan]

Problem

@atcute/jetstream rolls the cursor back 10s on the first connect when given an array url. That is deliberate (subscription.js seeds #lastUsedUrl = '' for arrays): a pooled set of instances is selected from at random each connect, so a resumed cursor may have come from a different instance, and the 10s rollback absorbs clock skew between them. It is designed to fire once per session.

Contrail's cron ingestion rebuilds the JetstreamSubscription every cycle. So for a single-instance config (e.g. the default ["wss://jetstream1.us-east.bsky.network"]), that "first-connect" rollback fires on every cycle and redundantly re-delivers the last 10s of events each tick. On a quiet stream this shows up as a duplicate-in-cycle flood; on a busy firehose it's a continuous ~10s re-ingest overlap.

Fix

Add a jetstreamUrlOption(jetstreams) helper in contrail-base that maps the configured list onto @atcute's url shape by topology:

• one instance → a string (one fixed instance, no skew, no rollback)
• a real pool (2+) → an array (cross-instance rollback preserved)

Applied at both construction sites: the cron ingestEvents path and the runPersistent daemon.

Note: setting two jetstreams does not sidestep this — an array keeps the per-cycle rollback and, with genuine cross-instance skew, the rollback is then actually needed every cycle. A string for the single-instance case is the only shape that removes the redundant re-ingest.

Tests

• jetstream-url-option.test.ts — the helper maps single→string, pool→array, empty→empty.
• jetstream-single-url.test.ts — ingestEvents hands a single configured jetstream to @atcute as a string and a multi-URL config as an array.
• jetstream-rollback-behavior.test.ts — a characterization test that drives the real JetstreamSubscription (mocking only the injected socket, not @atcute) and asserts array-url rolls the cursor back 10s while string-url does not. This pins the upstream behavior the fix relies on, so a future @atcute change fails here loudly instead of silently breaking the fix.

A changeset is included (patch).