[fix][broker] Clear delayed delivery state before resetting the cursor

[nodece]

Motivation

PersistentSubscription#resetCursorInternal reset the cursor without touching the delayed delivery tracker. The tracker state is a derived cache of the backlog (the source of truth is deliverAtTime in the message metadata), and a reset moves the consumption baseline, so the whole derivation is invalidated:

• bucket snapshots, index bits and queued entries from before the reset survived into the replay, and re-added messages deduped against the stale index instead of being re-tracked cleanly;
• in-flight trims/loads/deletes from before the reset could race the replayed state;
• the bucket cursor properties stayed on the cursor, so a later tracker recovery would load pre-reset buckets.

clearBacklog and unsubscribe already clear the delayed state for the same reason; the reset path was the odd one out.

Modifications

• resetCursorInternal now clears the delayed messages and waits for the clear to settle after disconnecting consumers and before asyncResetCursor; a clear failure unfences the subscription and fails the reset.
• Without a dispatcher there is no in-flight work and the recovered bucket snapshots stay valid for the replay (re-added messages dedup through the index bitmap), so there is nothing to clear.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• BucketDelayedDeliveryTest#testResetCursorClearsDelayedMessages: tracks 100 delayed messages, resets the cursor to the earliest position and verifies the tracker count is 0 and the bucket cursor properties are removed. Without the fix the assertion fails: the tracker still reports 100 delayed messages and the bucket cursor property survives the reset.

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

Check the boxes that apply

• 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