Configurable clear-to-closed hold time for alerts (replace the fixed 2-minute timer)

Current behaviour
In IBM Concert Operate (observed on 5.1.9), an alert that moves to Clear is moved to Closed after a fixed 2 minutes (unless it is part of an open incident), and this interval can’t be configured.
The only way to delay closure today is managedBySender on the Netcool connector. That works only for alerts that come from Netcool, and it moves the control to Netcool instead of keeping it in Concert Operate.

Why 2 minutes is not long enough
We run a multi-tenant managed network service where alerts drive ITSM tickets.

1. Flapping faults. Intermittent faults such as link flaps, routing session resets and power fluctuations often clear and come back within 3 to 10 minutes. Once the cleared alert is closed, the repeat creates a new alert instead of reopening the original one. The occurrence count resets, flap detection breaks, and correlation can raise a new incident and a new ticket for the same fault.
2. Syncing to other systems. We send alert state to ServiceNow through an external integration. If ServiceNow or the integration is briefly unavailable, retries can run past 2 minutes. If the alert closes first, the final state has to be rebuilt from history.
3. Operator verification. After a fix, operations team need to see recently cleared alerts in the live list to confirm the service is restored. A normal verification step takes longer than 2 minutes.
4. Incident closure. With alert-driven incident closure , an incident closes when all its alerts close. That makes the 2-minute alert timer the incident closure timer too.
   
   In Netcool/OMNIbus, the delete-clears interval is configurable. Customers lose that control when they migrate to Concert Operate.

Requested capability

1. A configurable clear-to-closed hold time, set globally, with overrides by alert filter (for example by source, alert type, severity or tenant).
2. If an alert with the same deduplication key comes back within the hold time, it reopens the same alert (same alert ID, occurrence count goes up) instead of creating a new one.
3. Optional conditional closure: a cleared alert stays open until a condition is met, for example a named alert attribute such as ticket state equals a given value.
4. A policy trigger when an alert closes, so automations can run before the alert leaves the live list.
5. The setting is available in both the UI and the API, so it can be managed as configuration-as-code.

Acceptance criteria

• An administrator can set the hold time from 0 up to at least 24 hours without involving IBM Support.
• The default stays at 2 minutes, so nothing changes unless someone configures it.
• The setting survives upgrades and matches on both clusters of a geo-redundant pair.