Incident Correlation View (group related incidents automatically)

## Feature: Incident correlation view across monitors

### Description

Currently, incidents are shown per individual monitor, with no way to see if multiple incidents are related.

When infrastructure issues occur (examples: network outage, database failure), multiple monitors may go down at the same time, but they appear as separate unrelated incidents.

### Problem

Users cannot easily identify:

- if multiple monitor failures are caused by the same root issue
- if incidents are isolated or part of a larger outage
- system-wide failure patterns

This makes debugging slower and increases time to identify root causes.

### Expected behavior

The system should group incidents that occur within the same time window into a “correlated incident group”.

Example:
- API service down at 14:00
- DB service down at 14:01
- Auth service down at 14:02

These should be grouped under a single “incident cluster”.

### Suggested solution
Add a correlation layer that:
- groups incidents based on time proximity
- optionally considers shared tags or monitor type
- displays grouped incidents in the incidents dashboard

### Affected areas

- Incident service (backend grouping logic)
- Incidents dashboard (frontend UI)
- API endpoint returning incidents

### Why this is useful

This improves incident analysis by:
- reducing noise in large systems
- helping users identify root causes faster
- providing system-level visibility instead of per-monitor view

Start by inspecting the incident service, incidents dashboard, and API endpoint that returns incidents. Trace how incidents are stored, fetched, and rendered, then define the grouping behavior and interface across these areas. Done means related incidents appear as one incident group while isolated incidents remain distinguishable.

Written by the indexing model from the issue text.