BulkRefreshCompletionListener may send duplicate notifications once #37249 is fixed

Description

BulkRefreshCompletionListener pushes a user-visible notification per JobCompletedEvent, with no guard on the event's identifier. System event delivery is at-least-once (documented in docs/backend/SYSTEM_EVENTS.md), so the same event can legitimately be observed more than once — which would send the submitting user a duplicate "bulk refresh finished" notification.

It cannot fire today, and that is the problem. JobCompletedEvent has no Jackson creator, so it never deserializes on a receiving node — the defect tracked in #37249. One bug is masking the other. Fixing #37249 makes this duplicate live.

The listener's own Javadoc already records the symptom without naming the cause:

Subscribing locally and pushing a purpose-built event also keeps the payload to plain counters, which crosses nodes safely, rather than depending on the job event classes deserializing on another node.

Found during the consumer idempotency audit for #36827, which reviewed all ten consumers of the queue. Every cache-invalidation consumer proved naturally idempotent (set(resolve…())); this one and SystemEventsWebSocketEndPoint were the two exceptions.

Acceptance Criteria

• Determine whether duplicate delivery of a JobCompletedEvent can reach this listener once #37249 is fixed.
• If it can, guard the notification on the event's identifier, which is stable across redeliveries.
• Automated test: the same event delivered twice results in one notification to the submitter.
• No behaviour change on first delivery.
• docs/backend/SYSTEM_EVENTS.md consumer audit table updated to reflect the outcome.

Additional Context

Sequencing — this should land with or immediately after #37249. On its own it fixes nothing observable; deferred past #37249 it becomes a live duplicate-notification bug.

Contract and consumer pattern table: docs/backend/SYSTEM_EVENTS.md. Related: #36827, #37249.

Start by locating BulkRefreshCompletionListener and reading its Javadoc, then review the consumer audit table in docs/backend/SYSTEM_EVENTS.md and the related context in #37249. Verify whether repeated JobCompletedEvent delivery reaches the listener, add a test for two deliveries of one identifier, and update the audit table; done means one notification on redelivery with unchanged first-delivery behavior.