[FR] Sortable table view for the Alerts page (with optional grouping)

[JonasAas]

Is your feature request related to a problem? Please describe.

The Alerts page currently renders every alert as a full-height card and can only be ordered by event time (ascending/descending). When a source produces many similar alerts — e.g. a single Suricata signature or a recurring EDR detection firing dozens of times — the page becomes a long scroll of near-identical cards, and there's no way to reorder by severity, status, source, customer, etc. to bring the important ones to the top. Triage means a lot of scrolling and per-alert clicking.

Describe the solution you'd like

An optional table view for the Alerts page, toggleable alongside the existing card view:

• Compact one-row-per-alert layout (id, severity, status, title, source,
  assignee, customer, time, tags), so far more alerts fit on screen.
• Sortable columns — click any column to sort the full filtered result set by it. Sorting is done server-side (extending the alert filter query), so it's correct across pagination, not just the current page.
• Click a row to expand inline detail; per-row actions (assign, status, merge, close) available without leaving the list.
• Optional "group by"(title/status/severity/source/customer) that collapses repeated alerts into counted buckets, with batch actions on a whole bucket — useful when one rule fires many times. This can be a follow-up if you'd prefer to keep the first change focused on the table + sorting.

Describe alternatives you've considered

• Keeping only the card view with more sort options — still one tall card per alert, doesn't solve density.
• Suppression/auto-accept ([FR] Ignore/accept alerts based on properties #828) — hides alerts rather than giving an overview complementary, not a substitute.
• This overlaps with [FR] Custom dashboard improve table and column options #1024 (improve table/column options); happy to align with that direction.

Additional context

I have an early prototype of the table view in a fork (screenshots below). The first shows 2417 alerts collapsed into 7 signature buckets — one rule accounts for 1338 of them, another 305, another 285. Group counts come from a server-side GROUP BY query so they reflect the full dataset, not just the current page. Buckets are sorted by volume and high-count groups get a darker badge so triage priority is immediately obvious. The second screenshot shows a bucket expanded to its individual compact rows.

Before building this out for upstream I'd appreciate guidance on: (1) given the UI migration to SvelteKit (the iris-frontend repo), should this live there as a new Svelte component, or as an enhancement to the current jQuery alerts.js in iris-web? (2) any preference on how column sorting plugs into the existing alert filter query — extend get_filtered_alerts with a sort_by param, or a separate endpoint? Happy to split into reviewable PRs and align with the roadmap.