[vbrzezina]

Problem

IngestionService.pollServer set servers.lastActivitySync to the maximum timestamp of every activity a provider returned. Providers also return synthetic rows stamped with the detection time (new Date()), such as *arr health checks and queue warnings.

A single such row moves the cursor to "now". History rows with event times between the old cursor and now that weren't returned in that poll (because of paging caps or API lag) are then never fetched again. This came up in the reviews of #58 and #62, and the *arr base provider has the same issue.

Fix

• NormalizedActivity gets an optional advancesSyncCursor flag. It defaults to true; providers set it to false on rows whose timestamp is the detection time rather than the event time.
• The cursor is computed only from rows that don't set the flag to false, in a small pure helper, computeSyncCursor. If no row qualifies, the stored cursor is left unchanged.
• The *arr base provider marks its health and queue rows advancesSyncCursor: false.

#58 (Bazarr) and #62 (qBittorrent) build on this.

Tests

• Cursor computation with mixed rows, only synthetic rows, and an empty batch.
• The *arr health and queue rows are flagged.

build, lint, typecheck and all test suites pass.

[vbrzezina]

Status: ready for review. This adds the optional advancesSyncCursor flag on NormalizedActivity, with the cursor computed in computeSyncCursor. Providers set it to false on rows stamped with the detection time (health and connection status, queue). The Bazarr, qBittorrent and Readarr PRs include this commit, so it will drop out of their diffs once this one is merged.