[fix][broker] Keep deduplication snapshots recoverable after skipped or failed attempts

[lhotari]

Motivation

Deduplication snapshots are asynchronous and intentionally allow only one cursor mark-delete at a time. At high publish rates, the entry threshold can expire several times before the current snapshot completes. This expected overlap currently emits a warning for every skipped attempt.

Two failure paths can also leave snapshotTaking set indefinitely. A publish completion can race with disabling deduplication and observe a null cursor after acquiring the guard, and asyncMarkDelete can throw synchronously before installing a callback. After either case, later snapshots are suppressed even after deduplication is enabled again.

Modifications

• Treat overlapping snapshot triggers as expected coalescing and log them at DEBUG.
• Capture and validate the managed cursor before acquiring the in-flight guard.
• Convert synchronous snapshot initiation failures to failed futures.
• Clear the guard from one completion path for both asynchronous success and failure.
• Preserve the existing snapshot interval, entry-counter behavior, cursor properties, and replay failure propagation.
• Add deterministic tests for overlap, asynchronous and synchronous failures, disable/re-enable races, stale cursors, and recovery retry behavior.

Validation

The change is based directly on current master and was verified with:

• Seven focused snapshot tests.
• BrokerMessageDeduplicationTest.
• MessageDuplicationTest.
• Full quickCheck.
• An end-to-end saturation run with one million warmup messages followed by five million measured messages from 500 stable producers to one topic and five ten-consumer Key_Shared subscriptions. All 30 million fanout deliveries arrived with no missing, duplicate, invalid, or out-of-order messages.

The same workload was profiled with and without this patch:

Revision	Measured ingress	Measurement window	Pending-snapshot warnings
parent	87,316 msg/s	57.263 s	3,414
candidate	83,438 msg/s	59.925 s	0

The candidate run experienced more CPU thermal throttling, and adjacent runs showed substantial cache and thermal variation. The table establishes that warning churn is removed while delivery remains correct; it is intentionally not presented as a throughput comparison. This change fixes snapshot recovery and removes misleading warnings rather than claiming a capacity improvement.

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment