4050e8d2 Added lag reporting for email analytics event processing
ref https://linear.app/ghost/issue/BER-3911
- The only signal for delayed email analytics processing was a one-off
log warning when the opened-events cursor fell behind a threshold, with
no way to tell from alerting or the admin how far behind we were or when
we caught up.
- The analytics wrapper now tracks a lagging state per pipeline: it
warns with structured fields (analytics.lagging, lag_minutes) on every
fetch cycle while behind, and logs a single analytics.caught_up event
with the peak lag and total time behind once the cursor recovers, giving
log-based alerting natural hysteresis. The lag can also be emitted as a
metric on every cycle, gated behind the new
emailAnalytics:metrics:openedLag:enabled config (default off), following
the existing open-throughput metric precedent.
- The analytics status endpoint additionally returns a lagMinutes value
per pipeline (opened, latest non-opened, missing), computed from the
persisted cursors so it is accurate even before the first fetch in the
current process, and the email debug screen renders these as Processing
lag rows alongside a new section for the opened events pipeline,
refreshing with the existing status polling.