Ensure archive groups only act on a fixed number of rows

[rbev]

Fixes: Particular/ServicePulse#3126

Problem

Failure-group Delete (archive) could show a negative remaining-message count when batches processed more messages than the count captured at the start. EF Core repeatedly queried the live group until it found a short batch, so messages arriving under sustained load could extend the operation indefinitely. RavenDB uses fixed batches, but its group count and batch contents come from separate indexes and can disagree. Restore (unarchive) has the same progress arithmetic. EF Core also counted fetched IDs as processed even when a row changed status before the bulk update.

Change

• Keep archive and restore totals at least as high as their processed counts, including when resuming an older operation. This prevents negative remaining counts and progress above 100%; both persisters persist the revised total during batch processing.
• Bound EF Core group archive and restore by the operation's planned batch count and stop when its processed count reaches the total. A short fetched batch still ends processing, so continuous arrivals cannot keep the operation running indefinitely.
• Recheck the source status in EF Core's bulk update and count its affected rows, rather than all IDs fetched for the batch. Keep the fetched ID count for the short-batch decision. Replay/retry accounting is unchanged.

Behavior and constraints

The operation processes a bounded number of live batches, not a snapshot of IDs. Messages that arrive during processing—and possibly some original members—can remain in the group for a subsequent operation. RavenDB's fixed batch loop is unchanged: reconciling the count prevents negative progress but does not process extra batches when its count and batch indexes differ. On completion, the existing finalization behavior reports the operation complete; batch events and per-message audit entries still use fetched IDs, which can include IDs skipped by the status recheck.

We chose to reconcile the operation's total rather than clamp only the displayed remaining count, because clamping would conceal a mismatch while leaving the operation's persisted totals inconsistent. We bounded EF Core's existing live-batch approach rather than materializing a snapshot of all message IDs, because leaving late arrivals for a later operation is acceptable.

Verification

• New EF Core tests cover bounded batches, late arrivals, persisted totals, and counting only affected rows.