Decide whether SystemEventsWebSocketEndPoint should de-duplicate at-least-once deliveries

Description

SystemEventsWebSocketEndPoint.sendSystemEvent(...) pushes every delivered event to connected admin sessions with no de-duplication by event 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 and the same UI update pushed twice.

Duplicates are not accidental — they are produced by design in two situations:

1. The overlap window. Each poll re-reads a bounded window behind its cursor so that a late-committing event is still delivered (#36827). Everything inside that window is read again.
2. Restart. The in-memory de-duplication set is empty after a restart, so the window may be re-delivered.

The poller suppresses repeats within a running JVM, so in steady state this endpoint should not see duplicates. The exposure is a node restart, or any future change to how the dedupe set is scoped.

What needs deciding

This is a judgement call about user-visible behaviour, not a clear defect — which is why it is filed for investigation rather than as a bug:

• For idempotent UI updates (a tree refresh, a status change), a duplicate push is harmless and de-duplicating adds cost for nothing.
• For notification-style events, a duplicate is visible to the user and looks like a bug.

The endpoint handles many SystemEventType values with different characters, so a blanket answer is probably wrong.

Found during the consumer idempotency audit for #36827, which reviewed all ten consumers. Every cache-invalidation consumer proved naturally idempotent; this and BulkRefreshCompletionListener (#37289) were the two exceptions.

Acceptance Criteria

• Classify which SystemEventType values reaching the websocket are duplicate-visible to a user, and which are harmless.
• For any duplicate-visible type, decide and implement: de-duplicate by event identifier at the endpoint, or make the client tolerate repeats.
• Automated test covering the chosen behaviour for at least one duplicate-visible type.
• No change to the authorization applied per session — validPayload / PayloadVerifier must continue to run per session per event.
• docs/backend/SYSTEM_EVENTS.md consumer audit table updated with the outcome.

Additional Context

Reproducing a duplicate requires a node restart with events inside the overlap window, or forcing the poller's dedupe set to be bypassed.

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

Start at SystemEventsWebSocketEndPoint.sendSystemEvent(...) and read the consumer pattern and contract tables in docs/backend/SYSTEM_EVENTS.md, along with the context from #36827 and #37289. Classify the SystemEventType values, choose endpoint or client handling for duplicate-visible events, preserve per-session validPayload / PayloadVerifier checks, add an automated test, and update the audit table.